Privacy
- Wat niemand over je mag weten
Privé CA automatiseren
28-06-2025, 12:41 door Anoniem, 7 reacties
Hoi Allemaal,
Voor wat diensten binnen m'n eigen netwerk gebruik ik nu certificaten van een eigen CA'tje. Ze hebben geen publieke naam, ze zijn ook niet publiek bereikbaar dus als ik een valide certificaat wil geven zie ik geen andere optie. Dit CA'tje staat nu op een gecrypte USB stick die ik alleen aansluit als ik er iets van nodig heb.
Dit werkt prima, maar betekend wel dat dit een handmatig proces is, en met zo'n 16 certificaten in gebruik wordt dat wat onhandig. Daarom heb ik ook gekozen voor een lange geldigheidsduur van 2 jaar, wat security wise misschien ook niet meer is wat je zou willen.
Met publieke certificaten zie je al langer de trend van kortere geldigheid en automatiseren en dat zou ik voor m'n interne CA'tje ook willen doen. Deels ter lering en vermaeck, deels om te zorgen dat ik er geen handmatig werk aan heb.
De grootste uitdaging: Hoe houd ik het veilig? Ik hoop dat jullie hier iets zinnigs over kunnen zeggen.
In z'n meest eenvoudige vorm kan ik natuurlijk een CA'tje bouwen, en daar certificaten mee maken en op de juiste plekken laten landen. Sowieso moet hij dan altijd beschikbaar zijn, dus offline is geen optie meer. Je kan vaak een password op de private key zetten, en omdat hij altijd beschikbaar moet zijn is dat de enige beveiligingsmogelijkheid die over blijft.
Maar ja: Dat password moet dan geautomatiseerd gebruikt kunnen worden, en hoe sla je dát dan weer veilig op? Alternatief is om hardware oplossingen te gebruiken, maar daar loop je tegen een soortgelijk probleem op: Voor toegang tot zo'n
oplossing heb je dan vaak weer een PIN code nodig, en waar ga je die opslaan?
Ongeacht welke methode ik ga gebruiken: Als de toegang beveiligd is met een password of PIN, als dat password of PIN ergens hardcoded in een script moet staan is de toegevoegde waarde voor de beveiliging ook 0.
Hoe kom ik uit deze catch-22?
Voor wat diensten binnen m'n eigen netwerk gebruik ik nu certificaten van een eigen CA'tje. Ze hebben geen publieke naam, ze zijn ook niet publiek bereikbaar dus als ik een valide certificaat wil geven zie ik geen andere optie. Dit CA'tje staat nu op een gecrypte USB stick die ik alleen aansluit als ik er iets van nodig heb.
Dit werkt prima, maar betekend wel dat dit een handmatig proces is, en met zo'n 16 certificaten in gebruik wordt dat wat onhandig. Daarom heb ik ook gekozen voor een lange geldigheidsduur van 2 jaar, wat security wise misschien ook niet meer is wat je zou willen.
Met publieke certificaten zie je al langer de trend van kortere geldigheid en automatiseren en dat zou ik voor m'n interne CA'tje ook willen doen. Deels ter lering en vermaeck, deels om te zorgen dat ik er geen handmatig werk aan heb.
De grootste uitdaging: Hoe houd ik het veilig? Ik hoop dat jullie hier iets zinnigs over kunnen zeggen.
In z'n meest eenvoudige vorm kan ik natuurlijk een CA'tje bouwen, en daar certificaten mee maken en op de juiste plekken laten landen. Sowieso moet hij dan altijd beschikbaar zijn, dus offline is geen optie meer. Je kan vaak een password op de private key zetten, en omdat hij altijd beschikbaar moet zijn is dat de enige beveiligingsmogelijkheid die over blijft.
Maar ja: Dat password moet dan geautomatiseerd gebruikt kunnen worden, en hoe sla je dát dan weer veilig op? Alternatief is om hardware oplossingen te gebruiken, maar daar loop je tegen een soortgelijk probleem op: Voor toegang tot zo'n
oplossing heb je dan vaak weer een PIN code nodig, en waar ga je die opslaan?
Ongeacht welke methode ik ga gebruiken: Als de toegang beveiligd is met een password of PIN, als dat password of PIN ergens hardcoded in een script moet staan is de toegevoegde waarde voor de beveiliging ook 0.
Hoe kom ik uit deze catch-22?
Reacties (7)
28-06-2025, 16:32 door
Anoniem
Door Anoniem: Hoi Allemaal,
[..]
Ongeacht welke methode ik ga gebruiken: Als de toegang beveiligd is met een password of PIN, als dat password of PIN ergens hardcoded in een script moet staan is de toegevoegde waarde voor de beveiliging ook 0.
Hoe kom ik uit deze catch-22?
[..]
Ongeacht welke methode ik ga gebruiken: Als de toegang beveiligd is met een password of PIN, als dat password of PIN ergens hardcoded in een script moet staan is de toegevoegde waarde voor de beveiliging ook 0.
Hoe kom ik uit deze catch-22?
Een knoop de ene of de andere kant op doorhakken .
Leermoment dat security allerlei trade-offs bevat , en dat ben je nu aan het ontdekken .
Goed voor je om te realiseren dat je gewoon een keus maakt waar je een bepaald risico plaatst, en dat ergens aan het eind van je analyse de conclusie is "als dit en dat en dat allemaal gebeuren ben ik compromised" .
vzviw hebben "echte" CAs een soort van pipeline die de te-signen certificaten op een heel complexe manier langs een "kan alleen maar signen" station met hardware module laat lopen .
Doel is dat de werkelijke CA private key 'onmogelijk' eruit kan lekken .
In de workflow daarbuiten moet de boel dan heel strak opgezet zijn dat ook alleen maar de bedoelde certificaten langs de "stempelautomaat" kunnen komen .
Het laden van de HSM is dan weer een proces van n-uit-m mensen met smartcards, trusted observers etc .
In jouw geval simuleer je dat misschien met een script met een pin (of een prompt die bij boot vraagt om de pin/passphrase) op een aparte vm die je dan maar "software hsm" noemt .
Of, als je all the way wilt gaan, kijk of je een 'echte' ergens tweedehands kunt scoren.
(klein beetje over te vinden bij RIPE,, die een CA voor rpki runnen)
https://labs.ripe.net/author/ties/securing-the-ripe-ncc-trust-anchor/
28-06-2025, 21:45 door
Anoniem
Leermoment dat security allerlei trade-offs bevat , en dat ben je nu aan het ontdekken .
Sorry, maar dan schat je me -op basis van alleen deze vraag- verkeerd in.Maar buiten dat:
Keuzes voor HSM, andere hard- of software oplossingen zijn de volgende stap. Ik probeer eerst conceptueel duidelijk te krijgen wat de opties zijn om het automatisch te doen en het ook veilig te houden, en uit jouw verhaal haal ik eigenlijk dat dat niet mogelijk is. Zelf was ik tot een soortgelijke conclusie gekomen, maar hoopte dat ik een optie over het hoofd zag.
Zelfs al zou ik de duurste HSM kopen die er is, als ik hetgeen wat de toegang daartoe geeft (of dat nou een PIN, key of wat dan ook is) ergens hardcoded in moet zetten dan heeft de HSM geen of weinig toegevoegde waarde.
Voor nu schat ik daarmee de risico's van een geautomaiseerde setup hoger in dan de risico's van m'n huidige werkwijze.
Gisteren, 03:05 door
Anoniem
Nitrokey heeft een prima oplossing. https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7#attr=
Daarmee kun je een prima echte CA maken, al dan niet heel complex en met automatische renewal op basis van bijvoorbeeld https://smallstep.com/docs/step-ca/cryptographic-protection/, je kunt ook daarmee op basis van een RPi en Yubikey een CA maken: https://smallstep.com/docs/step-ca/cryptographic-protection/#yubikey-piv. Leuk voor de hobby. :)
Daarmee kun je een prima echte CA maken, al dan niet heel complex en met automatische renewal op basis van bijvoorbeeld https://smallstep.com/docs/step-ca/cryptographic-protection/, je kunt ook daarmee op basis van een RPi en Yubikey een CA maken: https://smallstep.com/docs/step-ca/cryptographic-protection/#yubikey-piv. Leuk voor de hobby. :)
Gisteren, 12:05 door
Anoniem
Door Anoniem:
Maar buiten dat:
Keuzes voor HSM, andere hard- of software oplossingen zijn de volgende stap. Ik probeer eerst conceptueel duidelijk te krijgen wat de opties zijn om het automatisch te doen en het ook veilig te houden, en uit jouw verhaal haal ik eigenlijk dat dat niet mogelijk is. Zelf was ik tot een soortgelijke conclusie gekomen, maar hoopte dat ik een optie over het hoofd zag.
Leermoment dat security allerlei trade-offs bevat , en dat ben je nu aan het ontdekken .
Sorry, maar dan schat je me -op basis van alleen deze vraag- verkeerd in.Maar buiten dat:
Keuzes voor HSM, andere hard- of software oplossingen zijn de volgende stap. Ik probeer eerst conceptueel duidelijk te krijgen wat de opties zijn om het automatisch te doen en het ook veilig te houden, en uit jouw verhaal haal ik eigenlijk dat dat niet mogelijk is. Zelf was ik tot een soortgelijke conclusie gekomen, maar hoopte dat ik een optie over het hoofd zag.
"veilig" tegen welk soort aanvaller of risico ?
Je bouwt iets - en je wilt bereiken dat een aanvaller die hier of daar zit en zus of zo toegang heeft iets niet kan.
Zelfs al zou ik de duurste HSM kopen die er is, als ik hetgeen wat de toegang daartoe geeft (of dat nou een PIN, key of wat dan ook is) ergens hardcoded in moet zetten dan heeft de HSM geen of weinig toegevoegde waarde.
Wat is "toegang" ?
Wat de HSM bereikt is dat een private key die erin gestopt is - er ECHT NIET meer uitgehaald kan worden. Of in elk geval extreem veel moelijker (tamper proof dingen ) dan uit een draaiende normale server.
Wat de HSM _niet_ (vanzelf) bereikt is dat een aanvaller die aan de 'ingang' kan komen er ongewenst certificaten door kan laten signen .
Afhankelijk van je invulling van "toegang" is het ene dus wel iets waar een HSM meerwaarde heeft, en het andere is geen functie die je van een HSM krijgt , maar waar de rest van je "aanvraag" keten voor moet zorgen.
Voor nu schat ik daarmee de risico's van een geautomaiseerde setup hoger in dan de risico's van m'n huidige werkwijze.
Zoals ik zei , trade off....
Ja - als je extreem offline werkt ben je (nog) wat veiliger tegen een aanvals model waarin aanvallers online tot vlak bij je CA kunnen komen .
Als je CA langer online is dan 1x per twee jaar zijn er in principe wat meer kansen voor aanvaller om wat te doen, dat klopt.
Als je nog verder speculeert - hoe en waar je die private CA opslaat, en hoe veilig het is tegen aanvallers die fysiek in de buurt kunnen komen.
(een deel van de HSM security is tamper proof , en die dingen ook gewoon letterlijk achter veel deuren en sloten neerzetten ).
Het limiet geval is gewoon al je apparatuur uitzetten en bedenken dat je het alle online aanvallers nu ECHT lekker moeilijk gemaakt hebt.
Anway - nee, er zijn vzviw gewoon geen super slimme truken om "alles" perfect te krijgen . Een online variant met frequente refresh bouwen zal beslist erg leerzaam zijn .
Gisteren, 12:49 door
Anoniem
Door Anoniem:
"veilig" tegen welk soort aanvaller of risico ?
De risico's die ik zie zijn:"veilig" tegen welk soort aanvaller of risico ?
1) De CA moet op beschikbaar zijn, dus offline storage voldoet niet. Eventuele disk encryptie kan wel, maar de inhoud daarvan zal benaderbaar moeten zijn en beschermt dus alleen de data at-rest.
2) Eventuele beveiligingsmaatregelen die er voor zorgen dat niet zomaar een certificaat uitgegeven kan worden (pin, passphrase, key, whatever), zal naast de CA ook op het systeem moeten staan, daarmee is de beveiligingswaarde daarvan nihil.
3) Op ditzelfde systeem draaien (in containers) ook diensten die vanaf internet bereikbaar zijn.
Je bouwt iets - en je wilt bereiken dat een aanvaller die hier of daar zit en zus of zo toegang heeft iets niet kan.
In het kader van "assume compromise" wil ik de schade zo beperkt mogelijk hebben als het mis gaat. Een CA waar certificaten mee gemaakt kunnen worden die vervolgens door al m'n devices vertrouwd worden (en dus niet doorhebben dat er iets mis is) zie ik daarbij als een behoorlijk risico.Wat is "toegang" ?
Wat de HSM bereikt is dat een private key die erin gestopt is - er ECHT NIET meer uitgehaald kan worden. Of in elk geval extreem veel moelijker (tamper proof dingen ) dan uit een draaiende normale server.
Wat de HSM _niet_ (vanzelf) bereikt is dat een aanvaller die aan de 'ingang' kan komen er ongewenst certificaten door kan laten signen .
Dat waar ik op doelde met de catch-22 in m'n eerste bericht: Ik kan deze gegevens wel weer ergens anders in stoppen (desnoods in een hardware oplossing), maar ook die zal een authenticatiemiddel nodig hebben om toegang te geven, en waar laat ik die dan weer? Iedere oplossing brengt me terug naar hetzelfde probleem: Ik moet credentials ergens leesbaar neerzetten naast hetgeen wat ik wil beschermen. Het enige wat ik doe is meer hoepels creëren om doorheen te springen, er is echter niets wat er voor zorgt dat een ander niet ook door die hoepels kan springen op basis van de beschikbare gegevens.
Gisteren, 12:56 door
Anoniem
Door Anoniem: Nitrokey heeft een prima oplossing. https://shop.nitrokey.com/shop/nkhs2-nitrokey-hsm-2-7#attr=
Daarmee kun je een prima echte CA maken, al dan niet heel complex en met automatische renewal op basis van bijvoorbeeld https://smallstep.com/docs/step-ca/cryptographic-protection/, je kunt ook daarmee op basis van een RPi en Yubikey een CA maken: https://smallstep.com/docs/step-ca/cryptographic-protection/#yubikey-piv. Leuk voor de hobby. :)
Bedankt voor de tips.Daarmee kun je een prima echte CA maken, al dan niet heel complex en met automatische renewal op basis van bijvoorbeeld https://smallstep.com/docs/step-ca/cryptographic-protection/, je kunt ook daarmee op basis van een RPi en Yubikey een CA maken: https://smallstep.com/docs/step-ca/cryptographic-protection/#yubikey-piv. Leuk voor de hobby. :)
De link naar smallstep laat volgens mij mooi het probleem zien waar ik ook met andere setups tegenaan loop: In de benodigde commando's moet je een PIN meegeven. Iedereen die de PIN weet te vinden (en dat lukt, want die moet ergens op het systeem staan om er automatisch gebruik van te kunnen maken), die kan met de CA signen wat die wil.
Gisteren, 19:07 door
Anoniem
Ik draai zelf EJCBA (community edition) en serles-acme voor de ACME implementatie (die zit namelijk enkel in de betaalde versie van EJCBA). Werkt uitstekend met de acme.sh implementatie die vrijwel overal in zit.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?