[OpenSSL] Beveiliging van keys

[TheBlasphemer]

Een programma waarvoor ik een add-on schrijf gebruikt certificates om bepaalde content te checken.
Hierin heb ik een aanpassing gedaan zodat niet alleen de root-certificate van het betreffende programma geaccepteerd wordt, maar ook een eigen nieuw root certificate werkt.
Op deze manier kan ik dus ook custom content toevoegen mits mijn add-on is geladen
Al dit werkt al, maar ik zit nog een beetje in de knoop met een aantal certificate gerelateerde dingen:

een CRL (Certificate Revocation List) moet aanwezig zijn, en moet eens in de zoveel tijd aangepast worden. Echter om dat elke maand handmatig te doen is me eigenlijk een beetje te veel werk.
Maar om dit automatisch op de web-server te laten doen is een risico, aangezien de private-key dan ook daarop moet staan, en het al eens gebeurd is dat mensen via lekken in bijvoorbeeld IPB op de server zijn binnen gedrongen.

Omdat ik de boomstructuur van de originele certificaten zoveel mogelijk probeer na te bootsen, heb ik nu ongeveer 3 certificate authorities nodig:
Root certificate
Content PCA (Poliy Certificate Authority)
Content Authentication CA (Certificate Authority)
Het certificaat om content mee te signen.

Het leek mij misschien een optie om de root certificate handmatig te CRLen, en hierbij de levensduur van de CRL vrij hoog te zetten (bijv. een half jaar), terwijl in de PCA en CA op de server laat genereren, met een korte levensduur (bijv. maand).
Hiermee kan ik eind certificates toch netjes revoken via de CA, maar mocht de server gehacked worden en de private keys van de PCA en CA gestolen worden, dan kan ik deze alsnog revoken vanuit de Root. Ik weet dan alleen niet of het dan daadwerkelijk een half-jaar duurt voordat dit bij alle clients geupdate is.

Wat is hierbij een verstandige beslissing ?
De certificaten maak ik met OpenSSL, thuis op Windows XP, en op de server zou het op Redhat linux gebeuren.

[Equator]

Dat jij om het half jaar een CRL genereert houdt niet in dat je server pas na dat half jaar controleerd of een certificaat nog geldig is. Deze controle zou elke keer moeten gebeuren. Dus als jij na het intrekken van je intermediate CA (PCA) Certificaat een CRL genereert op de RootCA dan staat deze ook direct daarin. Deze vernieuwde CRL dient dan wel beschikbaar te zijn voor de server/client die er op controleerd.

Je zou ook iets van OCSP kunnen doen. OCSP staat voor Online Certificate Status Protocol. Die slaat de stap van het bouwen van een CRL over.

[VisionMaster]

Waarom heb je een twee laagse CA structuur? Het klinkt als overhead. Normaal gesproken zet je de CRL files gewoon online ergens en heb je de CA private key in een kluisje.

Ik zou ook inderdaad tijd investeren om te zien of OCSP geen prettigere oplossing kan bieden. Trouwens, mijn OpenSSL service doet het prima zonder CRL files. Als ik voor een CA in een CApath hebstaan zonder bij behorende CRL file, dan werkt het prima. Het is wel aan te raden om of CRL's of OCSP te gebruiken voor een serieuze CA

[Equator]

Wanneer jij een applicatie gebruikt welke de officiele PKI richtlijnen gebruikt (zoals bijvoorbeeld opgesteld voor gebruik binnen de overheid ) dan dient je PKI client te controleren of de CRL beschikbaar is. Indien deze niet beschikbaar is, dan stopt het geheel.

Voor een test is het natuurlijk makkelijk, maar in productie kom je er niet altijd onderuit.

Overigens wordt een CRL ondertekend - dus digitaal gesigned - door de uitgevende CA, en daarvoor heb je dus toegang nodig tot de private key van de CA. Natuurlijk kan je de CRL altijd op een willekeurige lokatie zetten.

De keuze voor een meerlaagse structuur kan soms als overhead worden gezien, maar het kan ook voor heel wat minder kopzorgen zorgen.
Het gebruik van een intermediate CA (een CSP bijvoorbeeld) welke gebruikt wordt voor het uitgeven van de client certificaten is handig omdat je bij echte problemen de intermediate CA nog kan intrekken, waardoor alle onderliggende certificaten automatisch ook invalid zijn.

Een goed voorbeeld is de structuur van het UZI-register. Zij maken gebruik van 4 CA hierarchie.

De eerste 2 zijn van de overheid zelf. Het Staat der Nederlanden Overheid CA heeft voor het UZI-register 1 CA certificaat uitgegeven (zijnde het CSP CA Certificaat).

De CSP CA heeft 4 CA certificaten uitgegeven. Zorgverlener, medewerker op naam, medewerker niet op naam en de services CA.
Zodoende kan een applicatie dus onderscheid maken op basis van het uiteindelijke certificaat wat door de gebruiker wordt aangeboden. Iemand die een zorgverlener certificaat heeft, mag bij voorbeeld niet aanmelden op applicatie X, waar iemand die een medewerker op naam certificaat heeft dat wel mag.

[VisionMaster]

Equator schreef op dinsdag 13 november 2007 @ 08:28:
Wanneer jij een applicatie gebruikt welke de officiele PKI richtlijnen gebruikt (zoals bijvoorbeeld opgesteld voor gebruik binnen de overheid ) dan dient je PKI client te controleren of de CRL beschikbaar is. Indien deze niet beschikbaar is, dan stopt het geheel.

Voor een test is het natuurlijk makkelijk, maar in productie kom je er niet altijd onderuit.

Overigens wordt een CRL ondertekend - dus digitaal gesigned - door de uitgevende CA, en daarvoor heb je dus toegang nodig tot de private key van de CA. Natuurlijk kan je de CRL altijd op een willekeurige lokatie zetten.

De keuze voor een meerlaagse structuur kan soms als overhead worden gezien, maar het kan ook voor heel wat minder kopzorgen zorgen.
Het gebruik van een intermediate CA (een CSP bijvoorbeeld) welke gebruikt wordt voor het uitgeven van de client certificaten is handig omdat je bij echte problemen de intermediate CA nog kan intrekken, waardoor alle onderliggende certificaten automatisch ook invalid zijn.

Een goed voorbeeld is de structuur van het UZI-register. Zij maken gebruik van 4 CA hierarchie.
[afbeelding]
De eerste 2 zijn van de overheid zelf. Het Staat der Nederlanden Overheid CA heeft voor het UZI-register 1 CA certificaat uitgegeven (zijnde het CSP CA Certificaat).

De CSP CA heeft 4 CA certificaten uitgegeven. Zorgverlener, medewerker op naam, medewerker niet op naam en de services CA.
Zodoende kan een applicatie dus onderscheid maken op basis van het uiteindelijke certificaat wat door de gebruiker wordt aangeboden. Iemand die een zorgverlener certificaat heeft, mag bij voorbeeld niet aanmelden op applicatie X, waar iemand die een medewerker op naam certificaat heeft dat wel mag.

De standaard OpenSSL libs zullen niet de CA stil leggen met een foutmelding als je geheel geen CRLs hebt voor een CA. Je zult moeten controlleren in je applicatie of die aan het geeiste beleid voldoet.

Al ik het goed begrijp dan heeft de UZI dus een bepaalde vorm van hun bedrijfsbeleid met authorisatie verweven. Zullen ze niet de meerlaagse CA structuur moeten bijwerken als er iets verandert in de relaties van bepaalde takken?

Er is iig geen technische reden om het zo te moeten doen. Aangezien dat er vele belanghebbende zijn bij iedere vertakking, betekent dit dat je het alleen als overheidsinstelling of groot bedrijf op zo'n grote manier goed kan aanpakken.

Mijn ervaringen met CAs zijn een beetje anders. In dit geval in de academische hoek voor Grid en Super Computing. De insteek van de PKI infrastructuur is wat anders.

EUGridPMA: www.eugridpma.org
IGTF: www.gridpma.org

Hoe VeriSign te werk gaat is weer anders, maar daar weet ik niet alles vanaf. Er zitten qua beleid van VeriSign wat haakjes en oogjes (plus de prijs!)

[ Voor 6% gewijzigd door VisionMaster op 13-11-2007 11:28 ]

[Equator]

VisionMaster schreef op dinsdag 13 november 2007 @ 11:16:
[...]

De standaard OpenSSL libs zullen niet de CA stil leggen met een foutmelding als je geheel geen CRLs hebt voor een CA. Je zult moeten controlleren in je applicatie of die aan het geeiste beleid voldoet.

Ik bedoel ook de applicatie waarmee je uiteidelijk gebruik gaat maken van de PKI omgeving.

Al ik het goed begrijp dan heeft de UZI dus een bepaalde vorm van hun bedrijfsbeleid met authorisatie verweven. Zullen ze niet de meerlaagse CA structuur moeten bijwerken als er iets verandert in de relaties van bepaalde takken?

Nee, UZI is alleen een CSP (Certificate Service Provider) voor de zorg. Het ontwerp is gemaakt samen met de opdrachtgever, naar de wensen van de opdarchtgever.
Er is echt wel over nagedacht denk ik

Er is iig geen technische reden om het zo te moeten doen. Aangezien dat er vele belanghebbende zijn bij iedere vertakking, betekent dit dat je het alleen als overheidsinstelling of groot bedrijf op zo'n grote manier goed kan aanpakken.

Niets moet natuurlijk Een bedrijf kan er natuurlijk voor kiezen om alles onder 1 CA te mikken.

Mijn ervaringen met CAs zijn een beetje anders. In dit geval in de academische hoek voor Grid en Super Computing. De insteek van de PKI infrastructuur is wat anders.

EUGridPMA: www.eugridpma.org
IGTF: www.gridpma.org

Hoe VeriSign te werk gaat is weer anders, maar daar weet ik niet alles vanaf. Er zitten qua beleid van VeriSign wat haakjes en oogjes (plus de prijs!)

Je betaald natuurlijk voor het feit dat VeriSign controleerd of de aanvrager van een certificaat wel diegene is die dat aan mag vragen.. (+ een stukje winst no doubt)

[VisionMaster]

Equator schreef op dinsdag 13 november 2007 @ 12:55:
[...]
Ik bedoel ook de applicatie waarmee je uiteidelijk gebruik gaat maken van de PKI omgeving.
[...]
Nee, UZI is alleen een CSP (Certificate Service Provider) voor de zorg. Het ontwerp is gemaakt samen met de opdrachtgever, naar de wensen van de opdarchtgever.
Er is echt wel over nagedacht denk ik

Daar mag ik wel op vertrouwen ja Maar het klinkt wel erg groot hoe die CA structuur in elkaar zit. Op zich had je het ook zo kunnen doen dat je locale RA's gebruikt. Althans, zo gebeurt het in mijn wereldje. Dat zijn mensen die weten wie er in een bepaalde tak van de namespace thuis hoort, zoals Sara, AMC, VU, Nikhef, <vul maar in>. Die namespace is gereserveerd voor een bepaalde organisatie en kan je niet buiten gaan. Dat is een manier waardoor je middels beleidswegen nog steeds je vertakte structuur kan terug vinden, maar met minder lagen, leg je meer macht terug bij de CA. In dit geval om eenvoudigere audits te kunnen doen van je CA en met minder mensen dezelfde soort vertakkingen te kunnen handhaven. Ook kan de CA zijn signing beleid aanpassen en heeft het directer effect op de uitgegeven certificaten.

[...]
Niets moet natuurlijk Een bedrijf kan er natuurlijk voor kiezen om alles onder 1 CA te mikken.

[...]

Je betaald natuurlijk voor het feit dat VeriSign controleerd of de aanvrager van een certificaat wel diegene is die dat aan mag vragen.. (+ een stukje winst no doubt)

Ja, dat klopt. De mankracht die in onze nationale CA voor Grid en super computing gaat is best aanzienlijk. Zeker als je (te snel) vergeet dat er altijd wel tijd gaat zitten in face to face paspoort controle, zowel voor de RA, de CA en de persoon die zijn gratis certificaat moet bemachtigen.