Vad är FIPS 140-2-överensstämmelse?

Om ditt arbete handlar om kontakter med amerikanska myndighetens IT, eller du producera hårdvaru- och / eller mjukvarulösningar som du hoppas kunna leverera till USA: s regering, du har troligtvis hört talas om FIPS 140-2-efterlevnad, men vad betyder det att vara FIPS-kompatibelt, och bör det betyda för dig?

Vad står FIPS för?

Förkortningen ”FIPS” hänvisar till ”Federal Information Processing Standards”. FIPS 140-serien är datasäkerhetsstandarder som fastställts av National Institute of Standards & Technology (NIST) för den amerikanska regeringen.

Ordlista

FIPS 140-2-standard uppfyller krypteringsnycklar och fysiskt skydd av dem. För dem som vill förstå vad allt detta men inte är kryptografiska proffs själva, här är en sammanfattning av några väsentliga termer.

• Kryptologi – handlar om forskning och utveckling av säkra kommunikationsmetoder, inklusive utveckling och utveckling av kryptering och andra metoder för att hålla data privata och säkra
• Kryptografisk nyckel – En klartextserie med tecken som används av en krypteringsalgoritm för att kryptera eller dekryptera text
• Kryptografisk modul – En enhet som hanterar kryptering, dekryptering, digitala signaturer, användarautentisering och generering av slumptal
• Critical Security Parameter (CSP) – Enligt NIST-ordlistan innehåller CSP: er säkerhetsrelaterad information vars avslöjande eller modifiering kan äventyra säkerhet för en kryptografisk modul
• Common Criteria (CC) – Även känd som Common Criteria for Information Technology Security Evaluation. Fungerar som den tekniska grunden för Common Criteria Recognition Arrangement (CCRA), ett internationellt avtal som säkerställer att säkerhetsprodukter testas på lämpligt sätt av oberoende licensierade laboratorier.
• Kryptering – Processen för kodning av ett meddelande eller en fil, vanligtvis med en algoritm utformad för att vara opraktisk för omvänd teknik, så att endast behöriga parter kan se den
• Plaintext – Text som inte har hashats eller fördunkits av en krypteringsalgoritm. Alla tillfälliga tittare kan se och läsa oskyddad och / eller okrypterad klartext

Vad är FIPS 140-serien?

FIPS 140 är en uppsättning krav och standarder för kryptografiska moduler för både programvara och hårdvarukomponenter för användning av amerikanska myndigheter och myndigheter. FIPS 140-2 är den andra och nuvarande (från och med den här bloggens publiceringsdatum) med FIPS 140-standarder som utfärdats av NIST. Släpptes den 25 maj 2001, FIPS 140-2 utökas med FIPS 140-1 (utfärdad 11 januari 1994), utnyttjar Common Criteria (CC) Evaluation Assurance Levels (EAL) för att bestämma säkerhetsnivå och beaktar återkoppling från samhället såväl som nya IT-utveckling och teknik sedan 1994.

Det är viktigt att notera att även om dessa standarder behandlar kryptografiska och säkerhetsstandarder för både hårdvara och programvara, garanterar inte en produkts efterlevnad av FIPS 140-2 säkerhet. FIPS 140-2 är endast avsett att tillämpas på kryptografiska moduler som interagerar med arbetsbelastningar som hanterar känslig men oklassificerad (SBU) information.

Vilka är utvärderingsnivåerna?

Vanliga kriterier fastställer sju ( 7) olika utvärderingsförsäkringsnivåer (EAL) benämnt EAL1-EAL7. Det är också vanligt att se ett ”+” bredvid en given EAL (t.ex. EAL5 +) för att beteckna att en viss enhet har uppfyllt vissa krav utöver minimumet för en given EAL. Eftersom den högsta nivån på FIPS 140-2 bara kräver EAL4, behöver vi kommer bara att diskutera EAL1-EAL4 i den här bloggen.

• EAL1: Avsedd för utvärderingsmål (TOE) där hot mot säkerheten inte betraktas som allvarliga, men det finns ett behov av förtroende för den implementerade säkerheten fungerar som avsett. EAL1 är värdefullt för att stödja påståendet att en viss organisation har lagt vederbörlig omsorg i skydd av personlig information. är inte tillgängligt, till exempel med långvariga äldre IT-miljöer
• EAL3: Designad för att ge en måttlig säkerhetsnivå. EAL3 tittar på TOE mer ingående, inklusive dess utveckling. Denna nivå är idealisk för organisationer med gedigna säkerhetstekniska metoder bakade in på desig n-nivå och som inte förväntar sig att behöva omkonstruera TOE väsentligt
• EAL4: Den högsta nivån som är ekonomiskt möjlig att eftermontera till en befintlig produktlinje (det vill säga testning och ombyggnad produkter som inte är byggda med högre EAL i åtanke kommer sannolikt att vara alltför dyra och tidskrävande). EAL4 är utformat för att ge maximal säkerhetssäkring baserat på bästa praxis för utveckling

Vilka är de olika nivåerna av FIPS 140-2?

FIPS 140-2-publikationen skapar fyra olika säkerhetsnivåer.Nivå 1 har lägsta säkerhetskrav, medan nivå 4 ger den högsta säkerhetsnivån.

FIPS 140-2 Nivå 1
Den lägsta säkerhetskrav som anges för en kryptografisk modul. Säkerhetsnivå 1 kräver inga fysiska säkerhetsmekanismer utöver grundläggande krav för produktionskomponenter och möjliggör att en kryptografisk modul kan köras på en dator för allmänt ändamål med ett ovärderat operativsystem.

Ett exempel på en Säkerhetsnivå 1 kryptografisk modul är ett krypteringskort på en persondator (PC).

FIPS 140-2 nivå 2
Säkerhetsnivå 2 utökas på säkerhetsnivå 1 genom att lägga till tre huvudkrav:

• Manipulära bevis på kryptografiska moduler: Detta kan innefatta manipuleringssäkra beläggningar, tätningar eller lås som är resistenta mot hack. Manipulära bevisåtgärder måste tillämpas på ett sätt så att tätningar och / eller beläggningar måste brytas för att få fysisk tillgång till kryptografiska nycklar och kritiska säkerhetsparametrar (CSP) i klartext.
• Rollbaserad autentisering: minimikrav för säkerhetsnivå 2 anger att en given användare måste ha sin specifika roll och auktoriseringsnivå autentiserad av den kryptografiska modulen PC som använder ett godkänt eller utvärderat pålitligt operativsystem. Operativsystem måste utvärderas på Common Criteria (CC) utvärderingsnivå EAL2 eller högre. Mer information finns i avsnitt 1.2 i FIPS 140-2-publikationen.

FIPS 140-2 nivå 3
Säkerhetskraven som fastställs av säkerhetsnivå 3 utökar de nivåer som ställs in på nivå 2. inom fyra nyckelområden:

• Intrångsförebyggande: Att gå längre än det manipuleringsbevis som implementerats på säkerhetsnivå 2, kräver säkerhetsnivå 3 fysiska säkerhetsmekanismer som är utformade för att förhindra att en inkräktare får tillgång till CSP inom kryptografin modul. Dessa mekanismer är avsedda att ha en hög sannolikhet att upptäcka och reagera på försök att fysiskt komma åt, manipulera eller använda en kryptografisk modul utan tillstånd. Exempelmekanismer inkluderar starka kapslingar och kretsar som är utformade för att nollisera (radera) CSP: er för ren text när en modul manipuleras.
• Identitetsbaserad autentisering: En mer detaljerad autentiseringsmetod, identitetsbaserad autentisering förbättrar den rollbaserade autentiseringskrav i säkerhetsnivå 2. Detta uppnås genom att autentisera en given användares identitet snarare än att autentisera användarens roll. Ett exempel på skillnaden är ett nätverk som kräver specifika användarinloggningar istället för ett nätverk som kan ha allmän användning eller gästkonton plus ett generiskt administratörskonto.
• Fysisk (eller logisk) separation: Att vara kompatibel med säkerhetsnivå 3 måste inmatning och / eller utmatning av CSP med ren text utföras med portar som är fysiskt (eller gränssnitt logiskt separerade, om en virtuell miljö) är separerade från andra portar. Plaintext-CSP: ar kan bara matas in i eller matas ut från den kryptografiska modulen genom ett omslutande eller ingripande system om de är i krypterad form.
• Krav på operativsystem: Precis som säkerhetsnivå 2, tillåter säkerhetsnivå 3 en kryptografisk modul som ska köras på en allmän PC med ett operativsystem som uppfyller minimikraven. Kraven på säkerhetsnivå 3 är strängare än nivå 2 och inkluderar en CC-utvärderingsnivå EAL3 eller högre. Mer information om kraven på operativsystems säkerhetsnivå 3 finns i avsnitt 1.3 i FIPS 140-2-publikationen.

FIPS 140-2 nivå 4 – Säkerhetsnivå 4 föreskriver högsta säkerhetsnivå för de fyra FIPS 140-2 säkerhetsnivåerna och är perfekt för kryptografiska moduler som fungerar i fysiskt oskyddade miljöer. För att få en uppfattning om vad som utgör en fysiskt oskyddad miljö, överväga var som helst myndighetsinformation eller kommunikation kan bearbetas, lagras eller överföras genom, såsom satelliter och obemannade flygfordon. Syftet med säkerhetsnivå 4 är att fysiska säkerhetsmekanismer helt ska omsluta och skydda den kryptografiska modulen från alla obehöriga försök att fysiskt komma åt den. Mekanismer måste ge en mycket hög sannolikhet för att detektera ett intrång och måste utformas för att omedelbart nollställa alla klartext-CSP: er om ett intrång upptäcks.

För att följa FIPS 140-2 nivå 4, en given kryptografi modulen måste också skyddas mot miljöförhållanden som kan skjuta modulen utanför dess normala arbetsområde. Det är vanligt att potentiella inkräktare skjuter en kryptografisk modul utanför dess normala spänning och temperatur för att äventyra modulens säkerhet.Exempel kan vara hyperuppvärmning eller frysning av modulbehållaren i ett försök att göra den spröd (överväga det populära filmmotivet för en spion som använder flytande kväve för att frysa och bryta ett lås).

Miljöskydd kan komma i form av funktioner som nollställer CSP: er om den kryptografiska modulen upptäcker fluktuationer utanför det normala driftsområdet. Med hjälp av exemplet ovan, om spionen i filmen skulle frysa ett lås till en kryptografisk modul för att bryta det, skulle miljöskyddsåtgärderna upptäcka att låset utsätts för temperaturer under en inställd tröskel och nollställa modulen. Detta gör det värdelöst för spionen, även om modulen så småningom erhålls.

Alternativt kan miljöskyddskravet uppfyllas genom en rimlig försäkran om att fluktuationer utanför det normala driftsområdet inte äventyrar modulens säkerhet.

Precis som säkerhetsnivå 2 och 3 kräver säkerhetsnivå 4 också ett operativsystem som uppfyller en viss säkerhetsnivå för CC-utvärdering. För att en kryptografisk modul ska kunna uppfylla FIPS 140-2 nivå 4 måste operativsystemet den körs få en CC-utvärdering av EAL4 eller högre.

Bli FIPS 140-2-certifierad

För att en viss kryptografisk modul ska kunna valideras som kompatibel med FIPS 140-2 måste en organisation skicka in den modulen till Cryptographic Module Validation Program (CMVP). CMVP är en gemensam insats av NIST och Communications Security Establishment (CSE) för den kanadensiska regeringen.

För att få sin modul utvärderad av CMVP måste en organisation överlämna modulen till en ackrediterad kryptografisk modultestning Laboratorium. Ackrediterade laboratorier är tredjepartslaboratorier som har certifierats av National Voluntary Laboratory Accreditation Program (NVLAP).

Att upprätthålla FIPS 140-2-certifiering

FIPS 140-2-certifiering kan vara lång och tidskrävande process, vanligtvis tar det flera månader till över ett år från början till slut. Dessutom måste en modul utvärderas för varje ändring av programvaran, oavsett hur liten. Om ett problem upptäcks i en FIPS-kompatibel modul förlorar lösningen sin FIPS-certifiering tills den har omprövats och certifierats. Under denna period kommer organisationen inte att kunna leverera sin modul till leverantörer och byråer som kräver standarden.

Kritik mot FIPS 140-2

Samtidigt som den valideras som FIPS 140-2-kompatibel är en väsentlig del av arbetet med amerikanska regerings IT, valideringsprocessen leder till viss giltig kritik av FIPS 140-2.

Den främsta punkten för kritik är relaterad till den långa valideringsprocessen. På grund av valideringsprocessen från månader till år och det faktum att en organisation måste ompröva sin produkt för varje ändring, oavsett hur liten, många företag är ovilliga att uppdatera eller uppgradera programvara även om ett fel upptäcks. Detta kan leda till att man hamnar efter på kritiska uppdateringar och kan till och med uppmuntra organisationer att dölja mindre buggar i sin kod.

Organisationer har upptäckt buggar och sårbarheter i sin programvara men möttes med svårigheter och en oklar process för att snabbt få en fix validerad som FIPS 140-2-kompatibel. I ett exempel upptäckte en organisation en sårbarhet i en certifierad modul och hade korrigeringsfilen klar för distribution samma dag men kunde inte få korrigeringsfilen validerad inom en lämplig tidsram. Resultatet var att organisationen tillkännagav sårbarheten i sin programvara och CMVP återkallade nästan omedelbart FIPS 140-2-valideringen och lämnade dem och deras kunder i limbo tills den nya valideringen slutfördes.

Vad som gör detta fall särskilt anmärkningsvärt är att sårbarheten hittades i ett öppen källkodsderivat av OpenSSL, som deras egen validering baserades på. Medan det fanns flera andra proprietära valideringar baserade på samma kod, fick få till ingen återkallelse. Detta beror på att andra organisationer något modifierade och omvaliderade koden under ett annat namn, snarare än att använda koden som identifierats som öppen källkod. Detta dolde effektivt kodens ursprung och andra företag kunde undvika återkallande till följd av en sårbarhet som finns i öppen källkod.

Frågor du borde ställa

Med tanke på kritiken från FIPS 140-2 valideringsprocess, alla organisationer som vill att deras kryptografiska modul ska användas av USA: s regering bör ställa modulskaparen några viktiga frågor:

• När uppdaterades den kryptografiska modulen senast / validerad?
• Finns det en ny version av den kryptografiska modulen som för närvarande genomgår validering?
• Finns det några kända buggar eller sårbarheter i modulen eller dess underliggande kod som kanske inte har avslöjats?
• Finns det planer på att uppdatera och / eller verifiera den kryptografiska modulen inom en snar framtid?
• Hur ser uppdateringsprocessen / kadensen för den FIPS-kompatibla modulen ut?
• Har den kryptografiska modulen genomgått någon testning eller validering utanför CMVP?

***

Om XMedius

XMedius är världsledande inom lösningar för företagskommunikation. Dess svit av företagsklassade lösningar och molnkommunikationslösningar gör det möjligt för företag att dra nytta av säker och enhetlig kommunikation, liksom att utbyta känsliga och konfidentiella data som uppfyller och överträffar kraven i branschens efterlevnadskrav. Baserat i Montreal (Kanada), med kontor i Seattle (USA) och Paris (Frankrike), betjänar företaget företag, företag och tjänsteleverantörer genom ett globalt team av kundfokuserade anställda. Dess lösningar distribueras över hela världen inom ett antal sektorer, inklusive utbildning, ekonomi, myndigheter, sjukvård, tillverkning, detaljhandel och juridiska tjänster. För mer information om XMedius och dess lösningar, besök www.xmedius.com och anslut via LinkedIn och Twitter.