In het kader van een vraag op de bugzilla lijst om meer informatie te geven over hoe het 'root' certificaat is beveiligd heb ik besloten om hier het een en ander te beschrijven en eens te zien of er nog anderen zijn die een beschrijving kunnen geven hoe het ook georganiseerd kan worden, of dat er nog betere ideeën om dit te beheren zijn.

Momenteel zijn er 2 hoofd servers, een webserver en een 'root' opslag server. De 'root' opslag server is uitsluitend door middel van een seriële kabel verbonden met de webserver. Een achtergrond proces zonder 'root' rechten draait aan beide kanten van de seriële kabel t.b.v. het oppakken/verzenden van aanvragen/gegevens.

Als de root opslag server een vreemd verzoek krijgt dan neemt die server aan dat de webserver beschadigd is en zal zichzelf afsluiten.

Als de 'root' opslag server geen 'ping' antwoord over de seriële verbinding krijgt binnen een vastgestelde tijd dan wordt er aangenomen dat de webserver beschadigd is of dat de 'root' opslag server zelf gestolen is. De root server zal zichzelf dan afsluiten.

Afgezien van het start gebeuren, verblijft alle data op een gecodeerde partitie op de root opslag server, alleen handmatig ingrijpen tijdens het starten van de server door invoer van een wachtwoord zal het proces weer starten.

De verzoeken die naar de root store worden gestuurd, worden in een bestand bewaard die vanuit een andere cron job opgehaald worden om te worden ondertekend, vervolgens in een antwoord bestand opgeslagen om terug gestuurd te worden naar de webserver. Dit zorgt er voor dat taken verdeeld worden over meerdere gebruikers, oftewel een standaard gescheiden verantwoordelijkheden oplossing. Dus als je al in staat bent om in de seriële processen in te breken, dan krijg je als meest slechte uitkomst dat er frauduleuze certificaten aangemaakt worden, maar het root certificaat zelf kan nooit in de openbaarheid komen.

U vraagt waarom een seriële kabel? Nou de bandbreedte die nodig is voor certificaat aanvragen is klein om te beginnen. Eenvoudige systemen zijn makkelijker te beveiligen en zullen moeilijker te kraken zijn. Ten slotte is de programmatuur voor seriële drivers dermate volwassen en doorgetest dat hopelijk alle mogelijke lekken inmiddels wel gevonden en opgelost zijn.

Met de voorgestelde 'root' certificaat wijzigingen komt er een nieuwe root, en deze zou ten minste één sub-root ondertekenen, en dan kan de privé sleutel in een bank kluis worden opgeslagen, waarbij de sub-root gebruikt wordt voor alle ondertekeningen. Of er komen 2 sub-root sleutels, een voor Client certificaten en een voor Server certificaten. De gedachte hierachter is dat als een van de sub-root sleutels beschadigd is deze ingetrokken en opnieuw uitgegeven kan worden.

Het is ook mogelijk om als we wat verder zijn wat meer beveiliging van de server te realiseren. Zoals 4 webserver die via 2 tussen servers contact hebben met de 'root' opslag, en in een token-ring achtige constructie werken. Als iets scheef gaat lopen dan zal de daar boven liggende server zichzelf direct afsluiten. Als dit gerealiseerd is en er zijn meerdere toegangspaden dan zal downtijd in een van de servers door andere servers die nog correct werken opgelost worden. Hoe dan ook hier kunnen we nog verder over denken.