Identifiera och minska risker vid PKI-bedömning

Dina PKI Design- och certifikatpolicy påverkar säkerheten för ditt nätverk och dina enheter som helhet. Du bör utforma och implementera din PKI för att avvärja typiska faror, ungefär som du skulle garantera att ditt hem har en jordbävningssäker grund eller ett orkansäkert tak.

Många av dessa val måste göras i förväg, under design och utveckling av din programvara eller produkt. Även om det krävs arbete för att implementera de nödvändiga säkerhetsåtgärderna i din PKI, kommer nödvändiga försiktighetsåtgärder att hjälpa dig att minska säkerhetsproblem i framtiden.

Tänk på detta. Vilken säkerhetsrisk skulle ett komprometterat certifikat i ditt nätverk utgöra? Kan en server nås med hjälp av certifikatets autentisering? Kan det användas mot dina användare i en man-in-the-middle-attack?

När man skapar ett program eller en enhet som använder certifikat för autentisering eller säker kommunikation bör dessa frågor noggrant övervägas. Tekniska val måste göras gällande hur er produkt ska hantera certifikat och hur er PKI ska utformas och hanteras.

Den här artikeln är avsedd för designers och producenter som arbetar med privata klient- eller enhetscertifikat, till exempel de som finns i programvara eller Internet av saker (IoT) enheter.

Skapa en PKI med långvarig säkerhet

Vi pratar ofta med utvecklare som inte känner till sina alternativ för att skapa PKI- och certifikatpolicyer. Du har stor flexibilitet med privat betrodd PKI när det gäller dina klient- och enhetscertifikat, vilket gör att du kan öka säkerheten för ditt program eller din enhet.

Vi kommer att gå in på detaljer om tre avgörande faktorer som du bör ta hänsyn till för att förbättra din PKI. Att välja giltighetstider och ersättning av certifikat, skydda privata nycklar och använda återkallelse av certifikat – samt hur man använder dessa kontroller effektivt för att minska risken – är de tre första ämnena.

Även om certifikat erbjuder autentisering och krypteringAtt använda dem är inte så enkelt som att bara installera dem och sluta använda dem. Båda dessa egenskaper kan äventyras, men med rätt åtgärder kan de också stärkas.

Den enklaste lösningen skulle kunna vara att ställa in en slarvig PKI och aldrig oroa dig för att hantera dina certifikat, men detta medför säkerhetsrisker som du kanske inte har tänkt på.

Låt oss använda den senaste nedläggningen av SHA-1 som en illustration. Forskare var medvetna om svagheten hos SHA-1-hashmetoden, som var utformad för att ge kryptografiska signaturer för att unikt identifiera certifikat. Förra året visade Google två olika filer med samma hash i en verklig kollision.

SHA-1-algoritmen utrotades effektivt av denna kollision, och många certifikat ersattes med den säkrare SHA-2-algoritmen för att upprätthålla säkerheten. Långlivade certifikat inkluderades också, vilka skulle bli mer exponerade med tiden (ökad datorkraft gör det lättare att utnyttja dem). Även om en SHA-1-kollision skulle verka omöjlig just nu, hur är det om 5 år? 20 år? Dessa är avgörande faktorer att ta hänsyn till om dina produkter kommer att användas under en längre tid.

Komplexiteten i PKI-säkerhet demonstreras snabbt av detta enkla exempel. Du skulle behöva en teknik för att återutfärda och ersätta certifikat på dina enheter, en återkallningsmekanism för att hantera certifikat som du vet har komprometterats, och en försäkran om att ditt nätverk och dina användare inte längre är exponerade för att minska säkerhetsriskerna med en felaktig hashalgoritm.

Giltighetstid för ett certifikat

I SSL / TLS I den här världen är komprometterade tekniker ett oundvikligt problem. Protokollets grundläggande kryptografiska tekniker är byggda med ett utfasningsdatum i åtanke eftersom vi förutser att starkare datorer i framtiden så småningom kan äventyra deras säkerhet.

Stora förändringar har skett under de senaste tio åren, såsom att hashalgoritmerna MD5 och SHA-1 har övergetts och att man har övergått till 2048-bitarsnycklar. Vi kommer så småningom att få slut på 2048-bitarsnycklar och behöva ersätta dem. Det kommer att bli mycket lättare att hantera dessa förändringar om man har en plan på plats.

Du måste väga fördelarna med ett långvarigt certifikat mot svårigheten att skydda långvariga nycklar när du bestämmer giltighetstiden för dina certifieringar. Att skydda dessa nycklar blir svårare med tiden i takt med att krypteringsstandarder försämras, ersätts och din samling av certifikat utökas. En bristfällig algoritm kan så småningom kräva att certifikat snabbt byts ut för att bibehålla säkerheten, som i fallet med vårt SHA-1-exempel.

Det är viktigt att tänka på både utgångsdatumet och processen för att ersätta dina certifieringar. För det mesta har vi upptäckt att det innebär för många säkerhetsavvägningar att försöka använda ett enda certifikat under hela enhetens livstid.

Genom att välja längre giltighetsperioder skapar du en större variation av certifikat (och tillhörande privata nycklar) som behöver hållas säkra. Eftersom det ger dem åtkomst under längre tidsperioder utökar detta antalet mål för angripare och motiverar dem att kompromettera ett certifikat. Detta gör i sin tur att det är viktigare att ha ett återkallelsesystem och kräver att man håller återkallelsedata till hands under längre tidsperioder, vilket resulterar i större återkallelsesfiler och större nätverksaktivitet.

Att skapa en säker PKI kräver dock inte att certifikat ändras varje år. Långlivade certifikat kan fortfarande användas samtidigt som effektiva planer för dessa ändringar görs. När du ersätter och förnyar enhetscertifikat kan du välja den giltighetstid som fungerar bäst för dig utan att behöva oroa dig för att du kommer att behöva ersätta dem i framtiden.

Håller privata nycklar säkert

Nyckelkompromettering delar många av samma säkerhetsfaktorer som certifikatgiltighet. Angripare kan imitera en enhet, dekryptera och läsa data och autentisera sig mot ett nätverk om de kan få tag på en privat nyckel.

Nycklar måste skyddas mot kompromettering, återkallas och ersättas om de någonsin komprometteras om du vill erbjuda verklig autentisering och kryptering. Det betyder att det inte är en bra idé att lägga nycklar på en enhet i klartext, där de lätt kan extraheras. Tänk istället på ett hårdvaruförsvar som ett säkert chip (TPM) eller en mjukvarulösning som ett krypterat nyckellager, vilket erbjuder verkligt försvar mot angripare.

Även om du tror att dina nycklar är tillräckligt skyddade är det avgörande att ha ett fungerande återkallelsesystem. Angripare kan bli intresserade av att hitta ett sätt att kringgå dina säkerhetsåtgärder om de upptäcker att det inte finns något praktiskt sätt att stoppa dem när de stjäl en nyckel. En ytterligare försvarslinje som kallas återkallelse tjänar till att neutralisera och avskräcka inkräktare.

Dessa hinder har mycket gemensamt. Ett pålitligt återkallelsesystem – ett som kan hantera en hög andel återkallelser – blir viktigare och dyrare om dina nycklar är enkla att kompromettera.

Återkallande

Eftersom återkallelse av certifikat är en "högkostnadstjänst" som kräver en aktiv internetanslutning och hög tillgänglighet, tror flera tillverkare och utvecklare att de inte kan stödja den. Så är inte fallet. Du kan kontrollera återkallningsinformation med hjälp av branschstandardteknik utan att ansluta till en server eller använda internet alls.

CRL (Certifikatåterkallningslistor) och OCSP är två tekniker som används flitigt i branschen för att verifiera återkallningsinformation (Online Certificate Status Protocol). En CRL är jämförbar med en svartlista med serienummer för certifikat för individer som inte är bekanta med dessa system. Med OCSP skickar klienten en begäran över internet till en central tjänst för att få reda på statusen för ett visst certifikats återkallelse – ungefär som att anropa ett API. X.509-certifikatprotokollet inkluderar både CRL- och OCSP-protokollen.

Det enklare alternativet, CRL, ger dig flexibilitet i situationer där din enhet kanske inte har en pålitlig eller snabb internetanslutning. Traditionellt signerar den utfärdande CA:n en CRL-fil varje dag, som klienten kan komma åt online. CRL:n kan dock cachas och lagras i situationer där enheten inte snabbt eller rutinmässigt kan ansluta till internet.

CRL:er är signerade och har en giltighetsperiod, precis som certifikat. CRL:er är tillförlitliga eftersom de är signerade av CA:n. En CRL behöver inte skickas direkt från CA:n till enheten. Istället kan de distribueras via ett nätverk, till exempel ett internt nätverk eller en centraliserad molnserver. Detta har en fördel jämfört med en enkel svartlista eller vitlista. Om en CRL-fil har en giltig signatur kan du ladda ner den från vilken plats som helst utan att oroa dig för manipulation.

När en CRL löper ut, vilket kan vara inställt på veckor eller mer, kan den cacha på en enhet och användas fram till dess. På grund av detta är det ett lämpligt val för enheter med ojämna eller oregelbundna internetanslutningar. Detta gör att du kan behålla fördelarna med återkallningskontroll i många situationer utan att ådra dig de tekniska kostnaderna för att upprepade gånger hämta ny data.

Så länge enheterna har tillgång till en gateway eller server som har det, kan OCSP även användas när enheterna själva inte har internetanslutning. Återkallningsinformationen kan överföras under TLS-handskakningen tack vare en valfri OCSP-funktion som kallas "häftning", vilket förbättrar nätverksprestanda. Både OCSP och CRL:er kan implementeras, där den senaste CRL:n fungerar som säkerhetskopia.

Att en kommersiell CA redan stöder en av dessa standardmetoder är en fördel med att använda den. De är flexibla standarder som kan anpassas för att möta dina unika behov eftersom de stöder ett brett spektrum av möjligheter.

Slutsats