Het identificeren en beperken van PKI-beoordelingsrisico's

Uw PKI Ontwerp en certificaatbeleid hebben invloed op de beveiliging van uw netwerk en apparaten als geheel. U moet uw PKI zo ontwerpen en implementeren dat deze typische gevaren afweert, net zoals u ervoor zou zorgen dat uw huis een aardbevingsbestendige fundering of een orkaanbestendig dak heeft.

Veel van deze keuzes moeten vooraf gemaakt worden, Tijdens het ontwerp en de ontwikkeling van uw software of product. Hoewel het implementeren van de vereiste beveiligingsmaatregelen in uw PKI werk kost, helpt het nemen van de nodige voorzorgsmaatregelen u om beveiligingsproblemen in de toekomst te verminderen.

Denk hier eens over na: welk risico vormt een gecompromitteerd certificaat op uw netwerk voor uw beveiliging? Kan een server worden benaderd met behulp van de authenticatie van het certificaat? Kan het tegen uw gebruikers worden gebruikt in een man-in-the-middle-aanval?

Bij het ontwikkelen van een programma of apparaat dat gebruikmaakt van certificaten voor authenticatie of beveiligde communicatie, moeten deze vragen zorgvuldig worden overwogen. Er moeten technische keuzes worden gemaakt over hoe uw product met certificaten omgaat en hoe uw PKI wordt ontworpen en beheerd.

Dit artikel is bedoeld voor ontwerpers en producenten die werken met privé-vertrouwensclient- of apparaatcertificaten, zoals die in software of Internet of Things (IoT) toestellen.

Een PKI creëren met langdurige beveiliging

We spreken regelmatig met ontwikkelaars die niet op de hoogte zijn van de alternatieven voor het creëren van PKI- en certificaatbeleid. Met private-trust PKI heeft u veel flexibiliteit als het gaat om uw client- en apparaatcertificaten, waardoor u de beveiliging van uw programma of apparaat kunt verbeteren.

We gaan dieper in op drie cruciale factoren waarmee u rekening moet houden om uw PKI te verbeteren. De eerste drie onderwerpen zijn het kiezen van de geldigheidsduur en vervanging van certificaten, het beveiligen van privésleutels en het gebruik van certificaatintrekking – evenals hoe u deze controles effectief kunt inzetten om risico's te beperken.

Hoewel certificaten authenticatie bieden en encryptie, het gebruik ervan is niet zo eenvoudig als ze simpelweg installeren en klaar. Beide eigenschappen kunnen in gevaar komen, maar met de juiste maatregelen kunnen ze ook worden versterkt.

De eenvoudigste oplossing zou kunnen zijn om een ​​slechte PKI op te zetten en u nooit meer druk te maken over het beheer van uw certificaten. Dit brengt echter beveiligingsrisico's met zich mee waar u wellicht nog niet aan heeft gedacht.

Laten we de recente veroudering van SHA-1 als voorbeeld nemen. Onderzoekers waren zich bewust van de zwakte van de SHA-1-hashmethode, die was ontworpen om cryptografische handtekeningen te geven om certificaten eenduidig ​​te identificeren. Vorig jaar toonde Google twee verschillende bestanden met dezelfde hash in een echte botsing.

Het SHA-1-algoritme werd door deze botsing effectief vernietigd en veel certificaten werden vervangen door het veiligere SHA-2-algoritme om de beveiliging te behouden. Ook certificaten met een lange levensduur werden opgenomen, die na verloop van tijd kwetsbaarder zouden worden (door de toenemende rekenkracht worden ze gemakkelijker te misbruiken). Zelfs als een SHA-1-botsing nu onmogelijk lijkt, hoe zit het dan over 5 jaar? Of over 20 jaar? Dit zijn cruciale factoren om rekening mee te houden als uw producten gedurende een langere periode worden gebruikt.

De complexiteit van PKI-beveiliging wordt snel duidelijk aan de hand van dit eenvoudige voorbeeld. U hebt een techniek nodig om certificaten op uw apparaten opnieuw uit te geven en te vervangen, een intrekkingsmechanisme om certificaten aan te pakken waarvan u weet dat ze gecompromitteerd zijn, en de zekerheid dat uw netwerk en gebruikers niet langer blootgesteld zijn om de beveiligingsrisico's van een gebrekkig hashingalgoritme te verminderen.

Geldigheid van een certificaat

In de SSL / TLS In de wereld van cybersecurity zijn gecompromitteerde technologieën een onvermijdelijk probleem. De fundamentele cryptografische technologieën van het protocol zijn ontwikkeld met een einddatum in gedachten, omdat we verwachten dat krachtigere computers in de toekomst uiteindelijk hun beveiliging in gevaar kunnen brengen.

Er hebben zich de afgelopen tien jaar grote veranderingen voorgedaan, zoals het afschaffen van de MD5- en SHA-1-hashalgoritmen en de overstap naar 2048-bits. Uiteindelijk raken we door onze 2048-bits sleutels heen en moeten we ze vervangen. Het zal veel gemakkelijker zijn om met deze veranderingen om te gaan als u een plan hebt.

U moet de voordelen van een certificaat met een lange geldigheidsduur afwegen tegen de moeilijkheid om sleutels met een lange geldigheidsduur te beschermen bij het bepalen van de geldigheidsduur van uw certificeringen. Het beschermen van deze sleutels wordt na verloop van tijd moeilijker naarmate encryptiestandaarden verslechteren, worden vervangen en uw verzameling certificaten groeit. Een gebrekkig algoritme kan uiteindelijk leiden tot het dringend vervangen van certificaten voor duurzame beveiliging, zoals in het geval van ons SHA-1-voorbeeld.

Het is belangrijk om na te denken over zowel de vervaldatum als het proces voor het vervangen van uw certificeringen. We hebben ontdekt dat het gebruik van één certificaat gedurende de levensduur van het apparaat vaak te veel compromissen op het gebied van beveiliging met zich meebrengt.

U stelt een breder scala aan certificaten (en bijbehorende privésleutels) in die beveiligd moeten worden door langere geldigheidsperiodes te selecteren. Omdat dit hen langere tijd toegang geeft, vergroot dit het aantal doelwitten voor aanvallers en motiveert het hen om een ​​certificaat te compromitteren. Dit maakt een intrekkingssysteem op zijn beurt belangrijker en vereist het bewaren van intrekkingsgegevens voor langere tijd, wat resulteert in grotere intrekkingsbestanden en meer netwerkactiviteit.

Het creëren van een veilige PKI vereist echter niet dat certificaten jaarlijks worden gewijzigd. Langlopende certificaten kunnen nog steeds worden gebruikt terwijl u effectieve plannen voor deze wijzigingen maakt. Wanneer u apparaatcertificaten vervangt en verlengt, kunt u de geldigheidsduur kiezen die het beste bij u past, zonder dat u zich zorgen hoeft te maken dat u ze in de toekomst moet vervangen.

Privésleutels veilig houden

Het compromitteren van sleutels heeft veel van dezelfde beveiligingsfactoren als de geldigheid van certificaten. Aanvallers kunnen een apparaat nabootsen, gegevens ontsleutelen en lezen, en zich authenticeren bij een netwerk als ze een privésleutel kunnen bemachtigen.

Sleutels moeten worden beschermd tegen misbruik, ingetrokken en vervangen als ze ooit worden gecompromitteerd, als u echte authenticatie en encryptie wilt bieden. Dit betekent dat het geen goed idee is om sleutels in platte tekst op een apparaat te plaatsen, waar ze gemakkelijk te achterhalen zijn. Denk in plaats daarvan aan hardwarematige beveiliging zoals een beveiligde chip (TPM) of een softwareoplossing zoals een versleutelde sleutelopslag, die daadwerkelijke bescherming biedt tegen aanvallers.

Zelfs als u denkt dat uw sleutels goed beveiligd zijn, is het cruciaal om een ​​functioneel intrekkingssysteem te hebben. Aanvallers kunnen geïnteresseerd raken in het vinden van een manier om uw beveiligingsmaatregelen te omzeilen als ze ontdekken dat er geen praktische manier is om ze tegen te houden wanneer ze een sleutel stelen. Een extra verdedigingslinie, intrekking genaamd, dient om indringers te neutraliseren en af ​​te schrikken.

Deze barrières hebben veel gemeen. Een betrouwbaar intrekkingssysteem – een systeem dat een hoog intrekkingspercentage aankan – wordt belangrijker en duurder als uw sleutels gemakkelijk te hacken zijn.

herroeping

Omdat certificaatintrekking een dure service is die een actieve internetverbinding en hoge beschikbaarheid vereist, denken verschillende fabrikanten en ontwikkelaars dat ze het niet kunnen ondersteunen. Dat is niet het geval. U kunt intrekkingsinformatie controleren met behulp van industriestandaardtechnologie zonder verbinding te maken met een server of internet te gebruiken.

CRL (Certificaatintrekkingslijsten) en OCSP zijn twee technologieën die veel worden gebruikt in de bedrijfswereld voor het verifiëren van intrekkingsinformatie (Online Certificate Status Protocol). Een CRL is vergelijkbaar met een zwarte lijst met serienummers voor certificaten voor personen die niet bekend zijn met deze systemen. Met OCSP stuurt de client een verzoek via internet naar een centrale service om de status van de intrekking van een bepaald certificaat te achterhalen – vergelijkbaar met het aanroepen van een API. Het X.509-certificaatprotocol omvat zowel het CRL- als het OCSP-protocol.

De eenvoudigere optie, CRL, biedt u flexibiliteit in situaties waarin uw apparaat mogelijk geen betrouwbare of snelle internetverbinding heeft. Traditioneel ondertekent de uitgevende CA dagelijks een CRL-bestand, dat de klant online kan raadplegen. De CRL kan echter in de cache worden opgeslagen in situaties waarin het apparaat niet snel of routinematig verbinding met internet kan maken.

CRL's zijn ondertekend en hebben een geldigheidsduur, net als certificaten. CRL's zijn betrouwbaar omdat ze door de CA zijn ondertekend. Een CRL hoeft niet rechtstreeks van de CA naar het apparaat te worden verzonden. In plaats daarvan kunnen ze via een netwerk worden verspreid, zoals een intern netwerk of een gecentraliseerde cloudserver. Dit biedt een voordeel ten opzichte van een eenvoudige zwarte of witte lijst. Als een CRL-bestand een geldige handtekening heeft, kunt u het vanaf elke locatie downloaden zonder u zorgen te maken over manipulatie.

Wanneer een CRL verloopt, wat ingesteld kan worden voor weken of langer, kan deze in de cache van een apparaat worden opgeslagen en tot die tijd worden gebruikt. Hierdoor is het een geschikte keuze voor apparaten met een haperende of onregelmatige internetverbinding. Hierdoor kunt u in veel situaties de voordelen van intrekkingscontrole behouden zonder de technische kosten van het herhaaldelijk ophalen van nieuwe gegevens.

Zolang de apparaten toegang hebben tot een gateway of server die dat wel heeft, kan OCSP ook worden gebruikt wanneer de apparaten zelf geen internetverbinding hebben. De intrekkingsinformatie kan tijdens de TLS-handshake worden verzonden dankzij een optionele OCSP-functie genaamd "stapling", die de netwerkprestaties verbetert. Zowel OCSP als CRL's kunnen worden geïmplementeerd, waarbij de meest recente CRL als back-up dient.

Het feit dat een commerciële CA al een van deze standaardbenaderingen ondersteunt, is een voordeel van het gebruik ervan. Het zijn flexibele standaarden die kunnen worden aangepast aan uw unieke behoeften, omdat ze een breed scala aan mogelijkheden ondersteunen.

Conclusie