Inhoudsopgave
Helaas kan ik geen hyperlinks maken van onderstaande onderwerpen. Tik Ctrl-F en zoek bijv. naar (Q11).

(Q00) Inleiding en toelichting
(Q01) Wat betekenen termen als algoritme, cipher, cryptografie, hash, encryptie?
(Q02) Wat is SYMMETRISCHE cryptografie?
(Q03) Wat is ASYMMETRISCHE cryptografie?
(Q04) Hoe ziet digitale asymmetrische encryptie er uit?
(Q05) Hoe werkt asymmetrische encryptie?
(Q06) Wat is public key cryptografie (of public key encryptie)?
(Q07) Wat zijn de toepassingen van public key cryptografie?
(Q08) Wat is HET GROOTSTE PROBLEEM van public key cryptografie?
(Q09) Kent public key cryptografie nog meer belangrijke problemen voor eindgebruikers en beheerders?
(Q10) Wat is een hash, en wat is een cryptografische hash?
(Q11) Hoe werkt bestandsverificatie m.b.v. een cryptografische hash?
(Q12) Wat is een digitale handtekening?
(Q14) Wat is een digitaal certificaat?


Wijzigingsregister
20120826 22xx Uitgebreide comments van Overcome (waarvoor mijn dank!) verwerkt.
20120821 0233 Q00: doelgroep omschreven (n.a.v. reacties van Anoniem).
20120820 2347 Na een terechte opmerking van Hugo in Q01 "decoderen" en "encoderen" goed omschreven.
20120819 2240 Q14 toegevoegd (wellicht zijn sommige lezers bijgelovig en er gaat al genoeg mis, dus geen Q13 ;)
20120819 1431 Inleiding bovenaan was te lang. Verplaatst naar nieuwe Q 00. Q 12 deels gevuld.
20120819 1114 Titel van Q09 aangepast en inhoud uitgebreid.
20120819 1048 Q10 en Q11 toegevoegd. Elders div. kleine wijzigingen.
20120818 2018 Eerste bijdragen geplaatst en een stel "gealloceerd".

(Q00) Inleiding en toelichting

Vooraf
Op het moment van schrijven (20120819 1430) is onderstaande FAQ nog lang niet af. Maar met name de m.i. aardige uitleg van asymmetrische enryptie wilde ik de eventuele hitte trotserende lezers tijdens dit zomerse weekend niet onthouden!

Aanleiding en doelgroep
In mijn ervaring zijn er in Nederland te veel systeembeheerders, ICT (security) consultants en managers met onvoldoende of geheel geen basiskennis van cryptografie om hun werk goed te kunnen doen. Ofwel het interesseert ze niet, of ze denken het te weten, of ze draaien eromheen. Dit geldt zowel voor het particuliere organisaties en bedrijven als voor de overheid.

Ook zie ik dat sommige bezoekers van security.nl onjuiste informatie posten (ongetwijfeld met de beste bedoelingen). Feitelijk zou elke computergebruiker meer van toegepaste cryptografie moeten weten om veilig te kunnen internetten!

Mijn hoofddoelgroep voor deze FAQ loopt van systeembeheerders tot en met ICT (security) consultants. Hopelijk heeft elke internetter er wat aan, maar cryptografie experts behoren absoluut niet tot de doelgroep (alhoewel hun input, met name als ik iets onjuist weergeef, enorm wordt gewaardeerd).

Ik hou de zaak dus zo begrijpelijk mogelijk voor iedereen. Je hebt geen uitgebreide wiskunde achtergrond nodig om deze FAQ te kunnen lezen. Helaas staan er wel veel begrippen in, dat is m.i. onvermijdelijk. Ik probeer ze zoveel mogelijk toe te lichten. Indien informatie te gedetailleerd dreigt te worden zal ik naar pagina's elders op het web verwijzen.

Nb. deze FAQ tracht behulpzaam te zijn in situaties als "ik heb een SSL certificaat nodig voor mijn webmail server". Bij meer complexe situaties (bijv. opzetten van een eigen PKI en met audits te maken kunnen krijgen) kan deze relatief korte en eenvoudig gehouden FAQ, relevante documenten natuurlijk niet vervangen. Daarbij kan worden gedacht aan o.a. ISO 21188:2006 "Public key infrastructure for financial services - Practices and policy framework" (bron: user Overcome in http://www.security.nl/artikel/42741/1/Comments_op_PKI_Certs_en_Public_Key_FAQ.html), ETSI documenten o.a. in http://www.etsi.org/website/technologies/electronicsignature.aspx en relevante RFC's (Requests For Comments), zie http://datatracker.ietf.org/doc/search/ (zoek bijv. naar public key).

Overheid en digitale veiligheid
M.b.t. de eerdergenoemde overheid constateert ook de Onderzoeksraad voor de Veiligheid dat het beter moet. Naar aanleiding van het Diginotar incident heeft zij onderzocht in hoeverre "de wijze waarop de overheid de veiligheid van de digitale communicatie met burgers waarborgt". In juni/juli van dit jaar heeft de Onzerzoeksraad daarover een aantal documenten gepubliceerd die hier te vinden zijn: http://www.onderzoeksraad.nl/index.php/onderzoeken/onderzoek-diginotar/.

Belangrijk: het gaat daarbij dus niet om wat er mis ging bij Diginotar, maar wat er beter moet bij de overheid! Zo bevat http://www.onderzoeksraad.nl/docs/aanbevelingen/Aanbevelingen_rapport_Het_Diginotarincident.pdf één A4tje met aanbevelingen voor de ministers van Binnenlandse Zaken, Veiligheid en Justitie en Economische Zaken, Landbouw en Innovatie.

Merkwaardig vind ik dan ook dat in https://www.ncsc.nl/binaries/nl/dienstverlening/expertise-advies/kennisdeling/factsheets/factsheet-verlos-me-van-een-botnet/1/Verlos%2Bme%2Bvan%2Been%2BBotnet.pdf (bron: http://www.security.nl/artikel/42720/1/NCSC%3A_Citadel_maakte_cliëntcertificaten_buit.html) niet duidelijk gemaakt wordt dat waarschijnlijk private keys zijn gestolen.

FAQ
Omdat ik te vaak moet uitleggen hoe het een en ander werkt, ben ik aan onderstaande FAQ (Frequently Asked Questions) begonnen, zodat ik daarnaar kan verwijzen. De volgorde is zo gekozen dat je deze van boven naar onderen kunt lezen als je "het hele plaatje" wilt begrijpen.

Ik probeer deze FAQ voor zoveel mogelijk mensen begrijpelijk te houden. Voor aanvullende informatie verwijs ik vaak naar andere websites. Diegenen die het allemaal te simpel vinden wat ik schrijf, en/of mij niet vertrouwen, verwijs ik naar o.a. de PKCS (Public Key Cryptography Standards) FAQ van RSA (http://www.rsa.com/rsalabs/node.asp?id=2153). Maar dan kom je wel "basispagina's" zoals "What is a hard problem" (http://www.rsa.com/rsalabs/node.asp?id=2187) tegen; het begrijpen van die pagina vind ik al een hard problem...

De FAQ is over meerdere bijdragen verspreid om deze makkelijker te kunnen bewerken. Ik zal een aantal bijdragen "reserveren" zodat ik de FAQ kan uitbreiden (zonder dat daar reacties van gebruikers tussendoor komen). De bijdrage hier direct onder bevat een inhoudsopgave, en daaronder zal ik ook de belangijkste wijzigingen en aanvullingen bijhouden.

Disclaimer
Het onderstaande heb ik naar eer en geweten geschreven, maar vanzelfsprekend weet ook ik niet alles. Het gebruik van welke informatie dan ook uit mijn bijdragen is dan ook geheel voor uw eigen risico. Correcties, aanvullingen en kritiek zijn natuurlijk van harte welkom!

(Q01) Wat betekenen termen als algoritme, cipher, cryptografie, hash, encryptie?

Algoritme: een beschrijving van een bewerking, in dit kader door een computer. Algoritmes worden door programmeurs in broncode omgezet. Broncode wordt door speciale software (o.a. compilers en linkers) in door computers uitvoerbare programma's omgezet.

Asymmetrische cryptografie: in tegensteling tot bij symmetrische cryptografie is hier sprake van een sleutelpaar of key pair. Wat met de ene sleutel wordt versleuteld, kan uitsluitend met de andere sleutel worden ontsleuteld (en vice versa).

CA: Certificate Authority (of Certification Authority). De partij die vaststelt of een aanvrager van een digitaal certificaat gerechtigd is om voor de gegeven "naam" een certificaat aan te vragen en vast te stellen dat die persoon is wie hij zegt te zijn. Indien beide kloppen zal de CA het de certificaataanvraag goedkeuren, voorzien van aanvullende gegevens en dit digitaal ondertekenen, waarmee een geldig digitaal certificaat ontstaat. Daarnaast is de CA verantwoordelijk voor het proces van (voortijdig) intrekken (revoken, revocation) van certificaten. Feitelijk is een CA een TTP (Trusted Third Party) omdat eindgebruikers erop moeten kunnen vertrouwen dat de CA bovenstaande taken goed uitvoert. Nb. de termen CA, CSP en RA zijn nauw aan elkaar verwant.

Cert: kort voor certificaat (digitaal). Niet te verwarren met CERT (Computer Emergency Response Team).

Certificaat (digitaal): in essentie is een digitaal ondertekend bestandje met daarin de "naam" van de eigenaar 9of webserver), zijn public key en de geldigheidsperiode van het certificaat. Gebruikelijk is dat de digitale handtekening is gezet door een CA, pas nadat die CA heeft "vastgesteld" dat de aanvrager de rechtmatige eigenaar is van de public key (of deze vertegenwoordigt).

Cipher: een specifiek algoritme (beschrijving van een methode) waarmee encryptie of decryptie plaatsvindt.

Cryptografie: de globale naam voor alle technieken waarbij sprake is van encryptie en decryptie.

CSP: Certificate Service Provider. Dit is de partij waar je zaken mee doet (de winkel zeg maar) als je een certificaat aanvraagt. Een CSP kan tevens CA zijn, maar kan die taak ook uitbesteden aan een derde partij. Nb. de termen CA, CSP en RA zijn nauw aan elkaar verwant.

Cypherpunk: mogelijk jij, als deze materie je interesseert ;) (zie http://en.wikipedia.org/wiki/Cypherpunk).

Decoderen: middels een gegeven algoritme, doch zonder sleutel, transformeren van gegevens.

Decryptie: ontsleutelen.

Encoderen: middels een gegeven algoritme, doch zonder sleutel, transformeren van gegevens.

Encryptie: versleutelen.

Hash: een soort checksum (optelsom) van alle byte-waarden van een bestand van willekeurige lengte. Een hash heeft, in tegenstelling tot een gewone checksum, altijd een vaste lengte (bijvoorbeeld 16 bits).

Hash, Cryptografische-: een wiskundig dusdanig ingewikkelde hash dat het in de praktijk onmogelijk is om twee verschillende bestanden te vinden die dezelfde cryptografische hash waarde opleveren (ook al verschilt maar 1 bitje tussen die bestanden); daarnaast mag het niet mogelijk zijn om, als je de hash kent, het oorspronkelijke bestand te kunnen berekenen (een gedeeltelijke uitzondering op dit laatste punt vormen de zogenaamde rainbow tables).

Key: sleutel. In het kader van deze FAQ bedoelen we, tenzij anders aangegeven, een cryptografische sleutel. Zo'n sleutel bestaat in de praktijk uit één of enkele getallen. Over het algemeen geldt dat hoe langer een bepaalt type sleutel is (hoe meer bits deze in beslag neemt) , hoe sterker hij is (moelijker te kraken). Je mag echter sleutellengtes van verschillende types niet met elkaar vergelijken. Bijv. een 256bit symmetrische AES sleutel is veel sterker dan een 512bit RSA sleutel (omdat totaal verschillende algoritmes worden gebruikt). Aangeraden sterktes (lengtes in bits dus) van verschillende sleuteltypes vind je bijv. in http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf.

Non-Repudiation: Het later niet kunnen ontkennen dat jij iets (digitaal) ondertekend hebt. Vergelijkbaar met een door jou gezette handgeschreven handtekening onderaan een papieren document (zie ook http://en.wikipedia.org/wiki/Digital_signature#Non-repudiation). Helaas denken mensen (ook rechters) te vaak dat digitale handtekeningen onfeilbaar zijn. Net zoals dat een handgeschreven handtekening onderaan een document vervalst kan zijn, kunnen digitale handtekeningen dat ook zijn (bijv. jouw private key kan gekopieerd zijn door een kwaadwillende, malware manipuleert jouw computer zodanig dat je een ander document digitaal signeert dan je voor je ziet, of de software die je gebruikt is gemanipuleerd waardoor deze een zwak of bij de aanvaller bekend sleutelpaar heeft gegenereerd).

PKI: Public Key Infrastructure. Een manier om public keys te verspreiden. Essentieel hierbij is dat duidelijk is en blijft wie de rechtmatige eigenaar is van elke public key. In de praktijk wordt een PKI meestal geassocieerd met hiërarchien van digitale certificaten (DCI, oftewel Digital Certificate Infrastructure, was m.i. een betere aanduiding geweest; immers feitelijk is http://pgp.mit.edu/ ook een PKI, zoek bijv. naar Werner Koch, de hoofdontwikkelaar van GNU Privacy Guard, ook bekend als GnuPG of GPG).
Het meest bekend is de publieke PKI, waarbij rootcertificaten van zeer veel en wereldwijd opererende CA's standaard in webbrowsers worden meegeleverd. Niets belet een organisatie echter om een eigen privé PKI te beginnen, zoals bijv. de USA DoD doet (zie http://dodpki.c3pki.chamb.disa.mil/rootca.html).

RA: Registration Authority. Deze partij verifieert o.a. de identiteit van de certificaataanvrager. Nb. de termen CA, CSP en RA zijn nauw aan elkaar verwant. In het plaatje in http://en.wikipedia.org/wiki/Public_key_infrastructure wordt getracht de relaties duidelijk te maken.

Symmetrische cryptografie: er is sprake van één sleutel waarom wordt versleuteld en ontsleuteld. Zowel de zender als ontvanger van versleutelde data moeten over dezelfde sleutel beschikken.

Aanvullende informatie:
- Algemene PKI begrippen, PKI Overheid in het bijzonder: http://www.logius.nl/nc/begrippenlijst/

- Hoofdstuk 3 in de Europese standaard ETSI TS 101 456, "eisen aan CA's" beschrijft veel definities en afkortingen: http://www.etsi.org/deliver/etsi_ts/101400_101499/101456/01.04.03_60/ts_101456v010403p.pdf

- De FAQ van CA/Browser Forum https://www.cabforum.org/faq.html. Het CA/Browser forum is een vrijwillig samenwerkingsverband van de meeste CA's en webbrowserfabrikanten (zie https://www.cabforum.org/forum.html voor haar leden).

(Q02) Wat is SYMMETRISCHE cryptografie?

Bij symmetrische cryptografie (ook wel symmetrische encryptie of secret key cryptografie genoemd) wordt dezelfde sleutel gebruikt voor het versleutelen als voor het ontsleutelen.

Dit is prima te vergelijken met het slot en de sleutel(s) van je voordeur: je kunt de voordeur zowel op slot doen als van het slot afhalen met dezelfde sleutel. Echter, je kunt die deur ook van het slot halen (of op slot doen) met een andere -qua vorm identieke- sleutel die je aan één of meer andere personen geeft die jij vertrouwt. Hetzelfde geldt natuurlijk voor een slot op een geldkistje of een kluis.Encryptie code: neem de ASCII waarde van elk inkomend karakter en tel daar de waarde van de sleutel bij op
Decryptie code: trek van elke versleutelde byte de sleutelwaarde af en voer het ASCII karakter van het resultaat uit

In dit voorbeeld heeft de sleutel de waarde 1 (dit staat bekend als een ROT1 cipher, vergelijkbaar met de ROT13 cipher die op http://en.wikipedia.org/wiki/ROT13 beschreven wordt). Dit is natuurlijk een belachelijk eenvoudig versleutelalgoritme, maar het principe is bij alle symmetrische algoritmes hetzelfde.

(Q03) Wat is ASYMMETRISCHE cryptografie?

Bij asymmetrische cryptografie (ook wel asymmetrische encryptie genoemd) worden verschillende doch complementaire (bij elkaar horende) sleutels gebruikt voor versleutelen en ontsleutelen.

Een essentiële eigenschap hierbij is dat je, wat je met de ene sleutel versleutelt, uitsluitend met de andere sleutel kunt ontsleutelen, en vice versa.

Wat je met sleutel 1 versleutelt, kun je dus niet meer ontsleutelen met sleutel 1, en wat je met sleutel 2 versleutelt, kun je dus niet meer ontsleutelen met sleutel 2!

Stel je hierbij een bijzonder slot van geldkistje voor, dat zo gemaakt is dat sleutel 1 alleen alleen rechtsom kan draaien (met de klok mee), en sleutel 2 alleen linksom. Bij een verder "gewoon" slot betekent dit dat de bezitter van sleutel 1 het geldkistje op slot kan doen maar daarna niet meer kan openmaken met diezelfde sleutel 1; alleen de bezitter van sleutel 2 kan dat.

Bij digitale asymmetrische encryptie wordt het nog interessanter: daarbij is het slot op het geldkistje zo geconstrueerd dat je door sleutel 2 verder linksom te draaien, het geldkistje ook kunt afsluiten. Zodanig dat deze uitsluitend met sleutel 1 te openen is! Het slot is verder zo geconstrueerd dat je beide sleutels er met de baard naar beneden, naar links en naar rechts (maar niet naar boven), zowel in kunt steken als uit kunt halen. Met zo'n geldkistje kun je dus geheime berichten uitwisselen met een ander die de complementaire sleutel heeft. Vanzelfsprekend moeten beide sleutels volstrekt geheim gehouden worden door de eigenaars!

In onderstaande "tekeningen" kijken we naar de slotzijde van het geldkistje, en dus naar deze kant: van de sleutels, en het plusteken geeft de kant van de baard van de sleutel aan:
Zoals je zult begrijpen kan het geldkistje tussen de stappen B en C, alsmede tussen de stappen F en G, veilig worden verzonden omdat het dan op slot zit.

(Q04) Hoe ziet digitale asymmetrische encryptie er uit?Een vergelijkbaar maar mooier plaatje vind je in http://asymmetriccryptography.com/.


(Q05) Hoe werkt asymmetrische encryptie?

In mijn bovenstaande "tekstplaatje" is te zien dat een digitale asymmetrische sleutel van het type RSA feitelijk uit twee getallen bestaat, waarbij één van die getallen gemeenschappelijk is: dat is de zogenaamde "modulus" (3233 in dit geval). Het getal 17 is de "exponent" van de linker sleutel en 2753 is de "exponent" van de rechter sleutel.

In de praktijk wordt meestal van de RSA methode gebruik gemaakt. In dat geval is de exponent vaak 65537 (2^16 + 1, oftewel hexadecimaal 10001), en de modulus vanzelfsprekend een "willekeurig" en hopelijk uniek getal met meestal een lengte van 1024 of, voor nieuwe sleutels, 2048 bits.

Om te begrijpen hoe asymmetrische encryptie in de praktijk wordt toegepast hoef je gelukkig niets van wiskunde te weten, maar het is wel handig als je weet dat zo'n asymmetrische sleutel meestal van het type "RSA" is en dan uit twee getallen bestaat.

Alleen voor de mensen die toch willen weten hoe dit werkt: er wordt gebruik gemaakt van de modulus functie en grote priemgetallen. De modulus functie is gewoon "het gehele getal dat de rest na een deling". Bijv. 23 modulus 10 is 3 (omdat je 20 twee keer door 10 kunt delen, dan rest drie dat geen geheel getal meer oplevert als je het door 10 deelt). Een priemgetal is een getal dat alleen door zichzelf en door 1 deelbaar is. Ik ga de wiskundige uitwerking hier niet uitschrijven, geïnteresseerden kunnen deze vinden in http://en.wikipedia.org/wiki/RSA_%28algorithm%29#A_working_example.

(Q06) Wat is public key cryptografie (of public key encryptie)?

Public key encryptie is volledig op asymmetrische encryptie gebaseerd, waarbij 1 key (sleutel) vrijelijk mag (en zelfs moet) worden verspreid! Dit wordt de public key genoemd. Essentieel is echter dat de complementaire private key strikt geheim blijft (dus uitsluitend in het bezit is -en blijft- van de rechtmatige eigenaar).


(Q07) Wat zijn de toepassingen van public key cryptografie?

Public key cryptografie leent zich voor twee verschillende zaken: versleutelen van informatie, of het zetten van een digitale handtekening onder informatie. Daarbij geldt:

- Versleutelen werkt uitsluitend in de richting van de bezitter van de private key, dus publiek -> eigenaar;

- Een digitale handtekening zetten heeft alleen zin als de bezitter van de private key dit doet, dus eigenaar -> publiek.

Als je dus een geheim document naar persoon X wilt sturen heb je zijn public key nodig. Daarmee versleutel je het document (de praktijk is iets ingewikkelder, zie verderop). Alleen de bezitter van de private key kan de geheime informatie dan nog uitpakken!

Bij het zetten van een digitale handtekening (ik leg verderop uit hoe dit werkt) gebruikt de zetter van de handtekening zijn private key. Iedereen kan aan de hand van de public key vaststellen dat de zetter van de handtekening in het bezit geweest moet zijn van de private key.

(Q08) Wat is HET GROOTSTE PROBLEEM van public key cryptografie?

Het is fundamenteel onmogelijk om met 100% zekerheid vast te stellen dat een public key "van iemand" of "van iets" is. Stel je wilt een document versleuteld naar de directeur van je bedrijf sturen en vindt op de website van jouw bedrijf de public key van de directeur. Maar wat nou als de systeembeheerder die public key heeft vervangen door zijn eigen public key, en tevens toegang blijkt te hebben tot de mailbox van jouw directeur?

Hier bestaan twee oplossingen voor, die beide helaas veel te wensen overlaten:
- Handmatig onderling uitwisselen van public keys;

- Elke public key verpakken in een eigen digitaal certificaat dat is ondertekend door een CA. Doordat we van de CA het rootcertificate (met daarin de public key van de CA) in onze webbrowser hebben onstaat een "chain of trust". In de praktijk wordt deze methode vaak met PKI (Public Key Infrastructure) aangeduid.

Beide methodes worden verderop toegelicht.

(Q09) Kent public key cryptografie nog meer belangrijke problemen voor eindgebruikers en beheerders?

Helaas wel:

(A): Private key in bestandje op PC of server
Als de private key op een computer wordt opgeslagen, terwijl die computer ook voor andere zaken dan opslag van sleutels en cryptografische bewerkingen wordt gebruikt, is het soms lastig om de private key geheim te houden.

Bijvoorbeeld een https webserver (die SSL/TLS ondersteunt) heeft de private key nodig tijdens een cryptografische bewerking om aan de bezoeker aan te tonen dat deze daadwerkelijk de bedoelde site (getoonde host.subdomain.domain.tld) bezoekt. In de praktijk bevindt die private key zich in een bestandje op de computer. Het webserver proces moet hier toegang tot hebben (en het wachtwoord kennen indien dat bestandje met een wachtwoord is versleuteld). Indien een aanvaller de server weet te compromitteren en dezelfde rechten weet te krijgen als het webserverproces, kan hij de private key kopiëren, en daarmee genoemde webserver spoofen.

(B): Private key op secure device
Indien de private key buiten de computer (bijv. op een smartcard, of -welliswaar in de PC- in een TPM chip) is opgeslagen (en de bijbehorende bewerkingen daarop uitgevoerd), kunnen aanvallers daar soms toch misbruik van maken, zonder dat ze die private key kunnen kopiëren. Dit is mogelijk als de computer zodanig gecompromitteerd is dat aanvallers (of hun code) de sessie kan manipuleren waarbij de gebruiker zijn private key gebruikt. Stel de gebruiker denkt met Adobe Acrobat een door hem geschreven document digitaal te ondertekenen. Het is denkbaar dat een aanvaller het documenten wijzigt (of geheel door een ander document vervangt) direct voordat dit door de auteur wordt ondertekend, en vervolgens de op het beeldscherm getoonde informatie zodanig manipuleert dat de auteur denkt zijn eigen document te hebben ondertekent. Zodra hij dit verzendt of publiceert gaat er natuurlijk iets anders de deur uit dan hij denkt. Dit type aanvallen is vergelijkbaar met MITB (Man In The Browser) aanvallen bijv. bij internetbankieren. Je denkt iets te doen, maar ondertussen gebeurt er in de achtergrond iets anders.

(C): Randomness
Vooral voor beheerders van belang: het is essentieel dat gegenereerde sleutelparen uniek zijn. Bij het genereren van sleutelparen wordt meestal gebruik gemaakt van een CSPRNG (Cryptographically Secure Pseudo Random Number Generator). Daarbij worden grote en willekeurige, onvoorspelbare en hopelijk unieke, getallen gegenereerd. Helaas is het bijzonder lastig om een computer iets onvoorspelbaars te laten doen!

In 2008 heeft een onoplettende Debian Linux programmeur per ongeluk een bug in de OpenSSL library (Debian only) geïntroduceerd waardoor er een predictable random number generator voor het genereren van asymmetrische sleutelparen ontstond (zie http://www.debian.org/security/2008/dsa-1571).

In feb 2012 hebben Arjen K. Lenstra et al de resultaten van een interessant onderzoek gepubliceerd (zie http://eprint.iacr.org/2012/064.pdf, bron: http://arstechnica.com/business/2012/02/crypto-shocker-four-of-every-1000-public-keys-provide-no-security/). Zij hebben zoveel mogelijk certificaten met daarin public keys verzameld en die op gemeenschappelijke factoren onderzocht. Daaruit bleek dat 0,4% van de public keys onvoldoende veilig is doordat deze ofwel identiek is aan een public key toebehorend aan een andere eigenaar, ofwel een gemeenschappelijke factor bevatte. Dit betekent dat de bezitter van 1 van de private keys de andere eigenaar direct kan spoofen, of dat met relatief eenvoudige berekeningen voor elkaar kan krijgen.

Vanwege de vaak kleinere resources, waaronder betrouwbare bronnen voor "randomness", beperkte rekencapaciteit, verouderde software en soms beperkt beschikbaar vermogen, is de kans op slechte randomness hoger bij embedded devices, SCADA systemen en smartcards, dan bij reguliere computers met up-to-date software.

Recent (zomer 2012) onderzoek op het gebied van onvoldoende randomness bij het genereren van RSA en DSA key pairs is te vinden op https://factorable.net/: (D): Ongeschikt voor versleutelen van bestanden
Asymmetrische cryptografieberekeningen zijn TRAAG; ze zijn ongeschikt om grote hoeveelheden informatie mee te versleutelen.

Hier bestaat de volgende (prima) oplossing voor:
- Je genereert een willekeurige SYMMETRISCHE sleutel;
- Daarmee versleutel je de informatie;
- Die symmetrische sleutel versleutel je met de public key van de bedoelde ontvanger;
- je stuurt zowel de (symmetrisch) versleutelde informatie, als de (asymmetrisch) versleutelde symmetrische sleutel naar de ontvanger.

De ontvanger kan de symmetrische sleutel uitpakken met zijn private key, en vervolgens daarmee de oorspronkelijke informatie ontsleutelen.

(E): Andere problemen
Bestaan er nog meer problemen? Jazeker. Maar die zitten vooral in de techniek, en zijn niet voor iedereen interessant. Denk daarbij aan brute force attacks, en bij smartcards, het achterhalen van de private key door het meten van variaties in het stroomgebruik tijdens het uitvoeren van crypografische berekeningen met die private key.

(Q10) Wat is een hash, en wat is een cryptografische hash?

Nb. dit is een nogal technisch verhaal, maar essentieel om digitale handtekeningen uit te kunnen leggen. Als je deze FAQ van boven naar beneden leest kun je deze bijdrage desgewenst overslaan, en indien nodig, later nog eens naar terugkijken.

(A) Gewone Hash
Een hash is een soort checksum (optelsom) van alle byte-waarden van een bestand van willekeurige lengte. Een hash heeft, in tegenstelling tot een gewone checksum, altijd een vaste lengte (bijvoorbeeld 16 of 32 bits).

Een voorbeeld van een hash is de optelsom van elke waarde van alle bytes in een bestand, en de uitkomst daarvan modulus 10 berekenen. Stel dat de optelsom van een gegeven bestand 83423 bedraagt, dan is "modulus 10" daarvan: 3 (de werking van de modulus functie leg ik uit onderaan Q05). Met andere woorden, de hash is altijd 1 (decimaal) cijfer lang.

Het hoofddoel van een hash is het detecteren van onopzettelijke wijzigingen in een bestand. Als er door een communicatiefout op een netwerk in dat bestand een letter "a" in een "b" verandert, zal de optelsom 83424 worden, en de hash dus 4.

Hoe gaat zoiets in zijn werk? De verzender van het bestand berekent, vóór verzending, de hash, 3 dus. Hij verstuurt zowel het bestand als de hash (dat ene cijfer) naar de ontvanger. De ontvanger berekent zelf ook de hash, en vergelijkt die met de meegestuurde hash. Als de hashes overeenkomen, terwijl je weet dat er veel communicatiefouten zijn (denk bijv. aan radiocommunicatie over grote afstanden) is de kans ongeveer 10% dat er toch iets misgegaan is. Hoe langer de hash, hoe kleiner de kans dat de meeste fouten onopgemerkt blijven.

Een simpele hash is totaal ongeschikt voor het detecteren van opzettelijke wijzigingen. Als een aanvaller "onderweg" het bestand in handen krijgt, kan hij ergens een "a" in een "b" veranderen en ergens anders een "q" in een "p" waardoor het ontvangen bestand dezelfde hash (uit het bovenstaande voorbeeld) zal hebben! Op vergelijkbare wijze kan de aanvaller de komma in een bedrag verplaatsen, ook dit levert geen andere hash op!

In de praktijk worden meer geavanceerde hashes gebruikt voor het detecteren van onopzettelijke wijzigingen. Zeer veel gebruikt zijn CRC (Cyclic Redundancy Check) hashes (of checksums). CRC's zijn veel beter (dan een simpele optelsom) in staat om typische fouten bij seriële communicatie (dus ook Ethernet en WiFi) te detecteren. Hoe CRC's precies werken ga ik hier niet op in (zie bijv. http://en.wikipedia.org/wiki/Cyclic_redundancy_check). Feit is dat het voor een aanvaller niet moeilijk is om een bestand "onderweg" zodanig te wijzigen (naar zijn hand te zetten) dat het dezelfde CRC oplevert.

Zie http://en.wikipedia.org/wiki/Hash_function voor meer informatie over hash functies in het algemeen.

(B) Cryptografische hash
Bij een cryptografische hash is veel meer sprake van versnijden. Tijdens het berekenen van de cryptografische hash worden de bytes van (een kopie van) het bestand stevig, doch op reproduceerbare wijze, door elkaar gehusseld, waarbij er tevens met de bits in de bytes geschoven wordt.

Wat er precies gebeurt is niet eenvoudig uit te leggen en dat is ook niet nodig voor het begrip. Het gaat erom dat je begrijpt dat voor een deugdelijke (nog niet geheel gekraakte) cryptografische hash het volgende geldt:

Noodzakelijk voor de veiliigheid:
1. Het is praktisch onmogelijk om twee verschillende bestanden (zowel met minimale als met enorme verschillen) te vinden die dezeldfe hash hebben (als dat gebeurt heet dit een hash collision en is er geen sprake meer van de deugdelijke cryptografische hash);
2. Je kunt, uitgaande van de hash, niet berekenen wat de inhoud van het oorspronkelijke bestand geweest moet zijn.

Gegeven:
3. Het maakt niet uit hoe lang het bestand is waar je de hash over berekent;
4. De lengte van de hash waarde (in bits) is altijd hetzelfde.

Er bestaan twee, heel verschillende, toepassingen van cyptografische hashes:
- Wachtwoordverificatie (vaststellen of de inloggende gebruiker het bijbehorende wachtwoord kent);
- Bestandsverificatie (vaststellen of een bestand ongewijzigd is).

Bekende voorbeelden van cryptografische hashfuncties zijn MD5, SHA-1 en SHA-2 (Nb. SHA-2 een verzamelnaam voor de volgende individuele crypto hashes: SHA-224, SHA-256, SHA-384 en SHA-512). Meer info over cryptografische hashes vind je hier: http://en.wikipedia.org/wiki/Cryptographic_hash_function.


Wachtwoordverificatie
Bij wachtwoordverificatie maakt het nauwelijks uit of een cryptografisch hash algoritme "gekraakt" is of niet. Immers, in de praktijk is het wachtwoord veel korter dan de hash. Daarbij is het nauwelijks interessant (en de kans erop is veel kleiner, omdat wachtwoorden meestal korten zijn dan de hash) als een aanvaller een ander wachtwoord kan vinden dat toevallig dezelfde hash oplevert; de kans dat de aanvaller een (slecht gekozen) wachtwoord raadt, of de database met gehashte wachtwoorden buit maakt, is veel groter.

Bij het gebruik van unsalted gehaste wachtwoorden kunnen rainbow tables een rol spelen. Voor het vullen van een rainbow table gebruikt men een bestand met veel voorkomende wachtwoorden en berekent van elk de hash. Als je vervolgens een wachtwoord-hash in handen krijgt kun je die hash waarde opzoeken in de rainbow table. Als je een match vindt heb je ofwel (enorm grote kans) exact het bijbehorende wachtwoord gevonden, ofwel (enorm kleine kans) een ander wachtwoord dat toevallig dezelfde hash oplevert (dat is dus tevens een collision). Echter, als de server unsalted hashes opslaat, maakt het niet uit of je het juiste wachtwoord, of iets anders dat toevallig dezelfde hash oplevert, invoert als wachtwoord.

Uitleggen wat salted wachtwoorden precies zijn, voert hier te ver. Zinvol kan zijn dat je begrijpt dat MD5 hashes, mits goed en random gesalt, best bruikbaar zijn op een (web) server waar gebruikers op inloggen. Er bestaat wel een goede reden om geen snelle cryprografische hash te gebruiken voor hashed passwords: aanvallers kunnen dan relatief snel rainbow tables maken. Het maakt dus weinig uit om MD5 door SHA-1 of SHA-2 te vervangen, allen zijn behoorlijk snel op moderne hardware. Om die reden zie je in bijv. https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet het advies om speciaal voor hashed password storage ontworpen algoritmes als bcrypt, PBKDF2 or scrypt te gebruiken (bron: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

Bestandsverificatie
Bij bestandsverificatie gaat het meestal om grotere bestanden dan de hashlengte. Het is evident dat collisions dan zullen bestaan. Waar het om gaat is hoe moeilijk het is om ze te vinden. Een zeer ernstige zaak is het als een aanvaller een bestaand bestand naar wens kan wijzigen zodanig dat het dezelfde hash oplevert.

Voorbeelden van serieus "gekraakte" cryptografische hash algoritmes voor bestandsverificatie zijn:
- MD2
- MD4
- MD5

Een nog zeer veel gebruikt, doch volgens sommigen al in 2005 gebroken (zie http://www.schneier.com/blog/archives/2005/02/sha1_broken.html) cryptografisch hash algoritme is SHA-1. De reden dat cryptografen als Bruce Schneier stellen dat SHA-1 gebroken is, is dat het minder sterk blijkt te zijn dan de uitvinders ervan hadden aangegeven.

Echter, er zijn geen momenteel publicaties die aantonen dat SHA-1 onbruikbaar is. Aan de andere kant is het best mogelijk dat instanties als de NSA en bijv. Chinese inlichtingendiensten SHA-1 veel verder gekraakt hebben dan bekend gemaakt wordt. Het is dus zaak om het gebuik van SHA-1 af te bouwen. Om die reden mogen PKI-overheid certificaten niet meer van SHA-1 (en ouder) gebruik maken.

Om je gerust te stellen, in http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html staat verder over de aanvallen op SHA-1: Maar.... dat artikel is ondertussen wel uit 2005!

(Q11) Hoe werkt bestandsverificatie m.b.v. een cryptografische hash?

Bestandsverificatie is het, door een ontvanger, vaststellen dat hij over exact hetzelfde bestand beschikt als de verzender.

Om dit met 100% zekerheid vast te stellen zou de ontvanger het bestand op een USB stick kunnen zetten, daarmee naar de verzender kunnen gaan en, bijv. middels FC /B in een "DOS box", vaststellen dat het om hetzelfde bestand gaat. Handig en gangbaar is deze methode natuurlijk niet.

Doel
Het doel is om met flinke zekerheid aan te tonen dat een bestand ongewijzigd is sinds het gemaakt werd, om precies te zijn tussen de volgende twee tijdstippen:

- Het moment dat de verzender, of iemand eerder in de keten (vaak de auteur, bijv. de programmeur) het bestand "goedkeurde";

- Het moment dat de ontvanger vaststelt dat het bestands sindsdien niet is gewijzigd.

Bij programma's zal in veel gevallen de programmeur een cryptografische hash over het bestand berekenen, en deze samen met het bestand op zijn website publiceren.

Voorbeeld: VLC
Op http://www.videolan.org/vlc/download-windows.html staan MD5 checksums en download links van de laatste versies van de VLC Media Player. Momenteel ziet de eerste download er ongeveer uit als volgt:Ik heb de actuele versie, vlc-2.0.3-win32.exe gedownload en daar de MD5 checksum over uitgerekend met een commandlineprogramma "md5sum.exe" dat ik ooit gedownload heb. Het resultaat is: ba39d5def71d5193ade6bfb24672a487. Deze door mij berekende waarde is dus identiek aan de op de website gepubliceerde waarde!

Garanties
Heb ik daarmee de garantie dat het om een betrouwbaar (bugvrij, adwarevrij en malwarevrij) programma gaat? Nee.

Noch hashes, noch digitale handtekeningen bieden daar ooit enig uitsluitsel over (ik begrijp nog steeds niet hoe Microsoft ooit meer vertrouwen kon hebben in "Signed" ActiveX components dan in "Unsigned"). Bijv. een virus op de computer van de ontwikkelaar kan het programma aanpassen voordat of nadat het een .exe werd (zie bijv. http://edn.embarcadero.com/article/39851 over het "Delphi virus").

Maar laten we er vanuit gaan dat alle programmeurs van Videolan te vertrouwen zijn, geen malware op hun computers hebben, noch bewust malware of adware verspreiden.

Okay, heb ik dan de garantie dat ik het identieke bestand in handen heb als de VLC programmeurs hebben vrijgegeven? Nee.

Voorbeelden van wat er allemaal mis kan gaan
- De meeste mensen hebben geen flauw benul wat MD5 betekent, en als ze dat al hebben, komen ze erachter dat ze standaard geen programma op hun Windows PC hebben om MD5 hashes uit te rekenen. Hoe kom je dan, op betrouwbare wijze, aan zo'n programma?

- Tot het moment dat de op de website getoonde MD5 hash berekend is, kan het bestand (zeer eenvoudig) gemanipuleerd worden. Een foute webmaster of een aanvaller met toegang tot de website kan zowel het bestand als de getoonde MD5 waarde wijzigen. In dit geval is het wijzigen van het bestand wat lastiger, omdat deze feitelijk vanaf andere websites wordt gedownload. Dat helpt. Maar niet genoeg.

- Hoe weet ik dat www.videolan.org de echte programmeurs van VLC vertegenwoordigt? Wellicht omdat deze site bovenaan staat als ik in Google naar VLC zoek? Okay, met VLC gaat dit wellicht goed, maar hoe zit het met andere programma's waar je naar zoekt? Criminelen zijn in toenemende mate bezig met een speciale variant van SEO (Search Engine Optimization), namelijk SEP (Search Engine Poisoning). Middels alle trucs die ze kunnen bedenken zorgen ze dat hun sites, die vaak als twee druppels water op de originele sites lijken, hoog eindigen in zoekresultaten van Google, Bing en andere zoekmachines. Zie bijv. een recent filmpje in http://www.bluecoat.com/company/news/cnn-clicked-search-engine-poisoning en een oudere writeup in http://www.readwriteweb.com/archives/search_engine_poisoning_1_vector_for_malware.php.

- Hoe weet ik dat ik met http://www.videolan.org/vlc/download-windows.html op de echte www.videolan.org site zit? Niet. Daar is "https" voor uitgevonden. Helaas geeft https://www.videolan.org/ een certificaatfoutmelding op de computer waarop ik deze tik.

- Daarnaast vond de download plaats als http://heanet.dl.sourceforge.net/project/vlc/2.0.3/win32/vlc-2.0.3-win32.exe. Ook dat is geen https. Een aanvaller met toegang tot mijn netwerk (doodeenvoudig als ik een publiek WiFi netwerk zou gebruiken) kan redelijk eenvoudig de getoonde webpage en de binary "on the fly" aanpassen (of vervangen voor iets geheel anders).

- Ten slotte is MD5 serieus gekraakt (zie bijv. http://www.win.tue.nl/hashclash/). Het is mogelijk om een bestand te wijzigen zodanig dat het dezelfde MD5 oplevert. Dus, stel dat http://www.videolan.org/vlc/download-windows.html geen certificaat foutmelding zou geven en ik op betrouwbare wijze de md5sum van het bedoelde bestand kan vaststellen, dan kan een aanvaller nog steeds de download zodanig manipuleren dat deze dezelfde md5sum oplevert.

Conclusie
In het gegeven voorbeeld kan zoveel mis gaan dat het nauwelijks de moeite waard is voor de gemiddelde eindgebruiker om op zoek te gaan naar een MD5 programma en braaf na elke download de check uit te voeren. Dit is totale schijnveiligheid. Het vervangen van MD5 door een nog niet (volledig) gekraakte cryptografische hash (zoals SHA-1 of SHA256) versterkt in het voorbeeld één schakeltje van de ketting.

Gelukkig kan het veel beter: de auteur kan een bestand digitaal ondertekenen. Daarbij wordt over het bestand een (hopelijk niet gekraakte) cryptografische hash berekend, en die wordt met de private key van de ondertekenaar versleuteld.

(Q12) Wat is een digitale handtekening?

Een digitale handtekening van een bestand is een met een private key versleutelde cryptografische hash over dat bestand.

Zo'n digitale handtekening kan achter het betreffende bestand geplakt worden of als los bestandje beschikbaar gesteld worden.

Doel
Het doel ven een digitale handtekening is dat iedereen met toegang tot de bijbehorende public key, met grote zekerheid kan vaststellen dat een bestand ongewijzigd is sinds dat bestand, eenduidig door een identificeerbaar persoon of instantie (d.w.z. als enige in het bezit van bijbehorende private key), is ondertekend.

Belangrijk: een digitale handtekening kan niet voorkomen dat een bestand gewijzigd wordt. Een bestand kan worden gewijzigd en daarna worden doorgegeven zonder digitale handtekening. Als de ontvanger niet weet dat het oorspronkelijke bestand digitaal ondertekend was, en het ontvangen bestand niet, dan valt dat wellicht helemaal niet op.

Als je als uitgever met digitale handtekeningen aan de gang gaat, is het zeer zinvol om daar ondubbelzinnig op over te stappen, net zoals dat banken nooit in een e-mail om jouw wachtwoord zouden moeten vragen, en websites die overgaan op https, http geheel zouden moeten uitbannen (inclusief automatische redirects van http naar https).

Slecht voorbeeld
Microsoft gaat de goede kant op, de meeste binary downloads zijn tegenwoordig voorzien van een digitale handtekening. Uitzonderingen bestaan echter helaas nog steeds. Vanaf bijv. http://www.microsoft.com/en-us/download/details.aspx?id=6315 kun je de "Windows Server 2003 Service Pack 2 Administration Tools Pack for x86 editions" downloaden, gepubliceerd op 29 oktober 2008.

Een vooruitgang is dat je diezelfde pagina ook als https://www.microsoft.com/en-us/download/details.aspx?id=6315 kunt bezoeken. Maar helaas, ook als je in die https pagina op download klikt, wordt het volgende bestand gedownload: http://download.microsoft.com/download/f/5/4/f541633c-6e89-4407-a69e-673dc7f2b485/WindowsServer2003-KB340178-SP2-x86-ENU.msi.

Dat bestand (.msi, feitelijk een executable) is (in elk geval op dit moment) niet voorzien van een digitale handtekening (en we hebben het hier niet over een screensavertje dat zonder admin rechten op een homecomputer kan worden gedraaid).

Soorten digitale handtekeningen
De meest toegepaste soorten digitale handtekeningen zijn:

- Puur public key gebaseerd is het PGP (Pretty Good Privacy) protocol. Zie http://en.wikipedia.org/wiki/Pretty_Good_Privacy en http://www.ietf.org/rfc/rfc4880.txt. Die standaard wordt onderhouden door de OpenPGP Alliance (zie http://www.openpgp.org/).

- Certificaat gebaseerd, in standaarden vastgelegd met name door RSA Data Security, Inc. Zie met name http://www.rsa.com/rsalabs/node.asp?id=2124.

Implementaties
Het bedrijf met de bekendste commerciële implementatie van PGP heet, net als het protocol, ook PGP (is tegenwoordig echter eigendom van Symantec, zie http://www.symantec.com/pgp).

De bekendste open source implementor van het PGP protocol is GnuPG (GNU Privacy Guard, zie http://www.gnupg.org/).

Er zijn veel bedrijven en organisaties die zich bezighouden met certificaat-gebaseerde digitale handtekeningen. Waar nodig zal ik daar verderop op ingaan.

E-mail
Er is nooit een goede standaard voor digitale handtekeningen onder e-mails tot stand gekomen. Als iedereen e-mails digitaal zou ondertekenen en ontvangers (de gebruikte mail client) de handtekening zou checken, zouden er heel veel minder spam, phishing, malware en identity spoofing mails in omloop zijn. Waarom bestaat zo'n oplossing dan niet?

- Mensen snappen cryptografie niet. Het interesseert ze niet en daardoor denken ze, terecht, dat ze een groter risico lopen als ze wel cryptografie zouden gebruiken.

- Maar ook mensen die wel wat van cryptografie weten zijn soms huiverig om e-mail digitaal te ondertekenen, omdat veel ontvangers er nauwelijks tot niets van begrijpen, en de kans groot is dat zij onterecht bewijs menen te zien dat ik een e-mail heb verzonden terwijl dat niet zo is. Dit staat overigens bekend als non-repudiation, d.w.z. het niet kunnen weerleggen dat jij iets hebt ondertekend.

- Het uitwisselen van public keys schaalt niet of is te onbetrouwbaar. Het gebruik van PKI certificaten is te duur.

- Veel mail clients ondersteunen digitale handtekeningen niet of onvoldoende. Daarbij komt dat er twee standaarden door elkaar lopen, PGP en S/MIME (zie bijv. http://www.oucs.ox.ac.uk/email/secure/).

(Q14) Wat is een digitaal certificaat?

Uit Q01: In essentie is een digitaal ondertekend bestandje met daarin de "naam" van de eigenaar, zijn public key en de geldigheidsperiode van het certificaat. Gebruikelijk is dat de digitale handtekening is gezet door een CSP (Certificate Service Provider), pas nadat die CSP heeft "vastgesteld" dat de aanvrager de rechtmatige eigenaar is van de public key (of deze vertegenwoordigt).

Uitleg aan de hand van een voorbeeld
In de praktijk zitten er meer gegevens in een certificaat, als voorbeeld neem ik het https certificaat dat automatisch naar jouw webbrowser wordt gestuurd kort nadat je https://secure.security.nl/ opent.

Hoewel er best veel informatie in dat certificaat staat (zie onder), gaan er voor dit certificaat maar 1092 bytes over de kabel! Als je bovenstaande gegevens in bijv. XML zou stoppen, zou je daar veel meer ruimte voor nodig hebben. Certificaten worden meestal in het zogenaamde ASN.1 formaat opgeslagen (zie http://en.wikipedia.org/wiki/ASN.1), dat zeer compact is. Als je het certificaat vanuit Internet Explorer als .DER bestand opslaat (bijv. op je bureaublad), dan wordt de lengte 1092 bytes.

Als je over dit bestand een SHA1SUM zou uitrekenen, krijg je 7163a65f95610d4587dd1b4e83324cdb1c8f6f81 als resultaat. Dat is dezelfde "Thumbprint" (NL: "Vingerafdruk") die je in de MSIE Certificate dialoogbox kunt zien als je de Details tab opent, alleen dan met spaties ertussen: "71 63 a6 5f 95 61 0d 45 87 dd 1b 4e 83 32 4c db 1c 8f 6f 81". Die Thumbprint komt zelf dus niet voor als waarde in het certificaat (bijv. Firefox geeft naast de SHA-1 thumbprint, ook een MD5 thumbprint weer).

Zoals ik heb geprobeerd te laten zien heeft het certificaat een hiërarchische opbouw. Het bestaat uit onderstaande hoofdonderdelen:

Subject
Het Subject bevat als enige belangrijke item de "CN" (Common Name) = secure.security.nl. Als die niet overeenkomt met wat de gebruiker als host.domain.tld in z'n URL bar ziet, moet de webbrowser een certificaatfoutmelding geven. De overige velden zijn, bij mijn weten, uitsluitend informatief.

Public Key Gegevens
De Public Key Gegevens beschrijven het gebruikte algoritme (RSA in dit geval) en de Public Key zelf (bestaande uit twee getallen).

Geldigheidsperiode
De Geldigheidsperiode van het certificaat spreekt voor zich. Overigens zijn deze hier in "lokale tijd" weergegeven, in het certificaat zelf staan ze in UTC (Universal Coordinated Time). Zou je dit certificaat in wintertijd (na de laatste zondag in oktober 03:00) bekijken, zul je zien dat de getoonde tijden 1 uur eerder zijn.

Gegevens van dit certificaat
De Gegevens van dit certificaat zijn deels nodig voor de webbrowser om het certificaat te kunnen interpreteren (versienummer en algoritme voor de digitale handtekening). Het serienummer is voor referentie door de CSP, en is waar naar wordt gerefereerd als een certificaat wordt ingetrokken (revoked).

Uitgever/Ondertekenaar (CSP)
Bij de Uitgever/Ondertekenaar (CSP) is (net als bij het Subject) de CN leidend, en de rest leuk om te weten. Die CN is essentieel voor de webbrowser om vast te stellen dat de CSP is wie hij zegt te zijn! Daarover verderop meer.

Extensions
De Extensions vormen een uitbreiding op oudere generaties certificaten en zijn meestal bedoeld om de beveiliging te verbeteren, waarbij Critical = True betekent dat een applicatie die het certificaat verwerkt en kennis heeft van de bijbehorende extensie, die specifieke extensie MOET naleven; bij Critical = False gaat het om een aanbeveling.

- "BasicConstraints" (basisbeperkingen): hieruit blijkt dat dit certificaat NIET als een CA certificaat gebruikt mag worden; Critical er direct onder betekent dat hier onder geen enkele voorwaarde van mag worden afgeweken!

- "Extended Key Usage": aangegeven wordt dat het certificaat bedoeld is als server- of als client-certificaat (voor SSL/TLS verbindingen). Gebruik voor andere doeleinden (bijv. e-mail signatures) wordt echter niet geblokkeerd.

- "CRL Distribution server": deze bevat een URL van een CRL (Certificate Revocation List). Een CRL is bestand met daarin een lijst van ingetrokken (revoked) certificaten.

- "OCSP server": het OCSP (Online Certificate Status Protocol) is een alternatieve (modernere en snellere) methode om vast te stellen of 1 specifiek certificaat is ingetrokken of niet.

Digitale Handtekening
De Digitale Handtekening is door de CSP onder het certificaat gezet. Daarbij heeft de CSP gebruik gemaakt van een asymmetrisch sleutelpaar dat niets te maken heeft met de public key in bovenstaand certificaat! En dat is logisch, het betreft een keypair dat gebruikt wordt om de authenticiteit van de CSP vast te kunnen stellen.

De digitale handtekening is 2048 bytes lang (dit is even lang als de modulus van de public key in het bovenstaande certificaat, maar dat is niet noodzakelijkerwijs zo). Het voert te ver om uit te leggen hoe deze signature tot stand is gekomen, maar het volgende wil ik wel kwijt:

- Deze signature is even lang als de modulus van het door de CSP gebruikte keypair, in dit geval 2048 bits (oftewel 258 bytes);

- De CSP heeft de inhoud bepaald door eerst de SHA-1 hash over "het Certificaat zelf" te berekenen (20 bytes lang) en deze vervolgens aan een speciale encoding te onderwerpen. De output daarvan en de private key van de CSP ondergaan vervolgens een cryptografische bewerking met de 2048 bits lange signature als resultaat. Voor de crypto-details zie ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf §8.1.1 en §9.1.1.

gereserveerd

Todo:
- PKI (en http://www.schneier.com/paper-pki.html)
- Certificate chains
- Browser trust en certificate stores
- Revocation
- Zelf genereren sleutelparen en CSR
- Bescherming private keys
- en http://www.win.tue.nl/hashclash/Nostradamus/ (PDF's)

gereserveerd

gereserveerd

gereserveerd

gereserveerd

gereserveerd

Een goede actie om dit te schrijven. Ik vrees voor je dat het weinig helpt en dat mensen hier evenzeer hun onkunde zullen blijven etaleren, maar het is een goede poging.

Klein beetje commentaar op bovenstaande formulering : Het woord 'willekeurig' suggereert dat een RSA modules een 'random' getal is. Dat is zeker niet het geval;
Het is een getal wat het product is van twee priemgetallen van ongeveer gelijke grootte.
Die priemgetallen horen inderdaad willekeurig gegenereerd te zijn , maar noch de losse priemgetallen, noch hun product zijn een 'willekeurig' getal in de normale (cq wiskundige) betekenis van het woord.

Ik zou formuleren : De modulus is het product van twee willekeurig gekozen priemgetallen van 512 of 1024 bit. De modulus is dan 1024 bit (bij priemgetallen van 512 bit). Tegenwoordig kiest men meestal voor moduli van 2048 bit, waarvoor de priemgetallen dus elk 1024 bit lang zijn.
De exponent en de modulus vormen samen het publieke deel van een RSA sleutel.

Ook hier heb ik een paar opmerkingen :
Het is misschien niet helemaal duidelijk, maar een lengte van "bijvoorbeeld 16 bits" is niet serieus als cryptografische hash, en zelfs als simpele error checksum aan de korte kant.

De eigenschappen die je noemt voor een cryptografische hash zijn niet compleet.

Dat de hash een vaste output lengte heeft is heel erg normaal, absoluut ook voor error detectie hashes zonder cryptografische ambitie. In bijna alle soorten gebruik ligt de beschikbare ruimte voor de checksum vast (disk blocks, communicatie protocol, ip/tcp headers, format van bv zip archieven).

Ook een input van onbeperkte lengte is geen eis die speciaal voor cryptografische hashes.

Wat _wel_ bijzondere eisen zijn, zijn de volgende :

1st pre-image resistant : het is "moeilijk" om een input te vinden met een gegeven hash-waarde als uitkomst.
2nd pre-image resistant : het is "moeilijk" om gegeven een input en hash waarde, een andere input te vinden met dezelfde uitkomst
en collision resistant : het is "moeilijk" om twee inputs te vinden met dezelfde hash waarde als uitkomst.

MD5 is gebroken mbt tot collision resistance, en dat is genoeg om te diskwalificeren als cryptografische hash, maar er is geen 1st of 2nd pre-image attack tegen MD5 bekend.

"Moeilijk" is hier "beter dan brute force" , en "beter dan birthday attack" voor collision resistance.
De lengte van een cryptografische hash functie moet zodanig zijn dat "brute force" ook inderdaad buiten de mogelijkheden ligt, ook van hele datacenters vol met GPU kaarten.

LET OP!

Reacties, correcties, aanvullingen en meningen s.v.p. NIET HIERONDER maar
hier: https://secure.security.nl/artikel/42741/1/Comments_op_PKI_Certs_en_Public_Key_FAQ.html
of hier: http://www.security.nl/artikel/42741/1/Comments_op_PKI_Certs_en_Public_Key_FAQ.html

Nb voordat ik op zondag vroeg om niet onderaan deze pagina te posten, waren bovenstaande reacties nog niet zichtbaar (nog niet vrijgegeven door moderator). De auteur(s) van genoemde reacties valt echter niets te verwijten, want hij of zij had deze reacties al gepost voordat ik deze oproep plaatste!

Mijn reacties op bovenstaande comments vind je via bovengenoemde URL's.