Auteurs: Jennifer Brady en Apurva Varalikar

Tot dusver hebben we de verwachte tijdlijn van de geplande FIPS 140-3-overgang uiteengezet (Key FIPS 140-3-datums), en de belangrijkste termen en definities die u moet kennen (Deel 1: Sleutelbegrippen en definities). Vandaag gaat onze blogserie verder met de verschillen tussen FIPS 140-2 en FIPS 140-3. Dit bericht behandelt de afzonderlijke secties van de ISO / IEC 19790 / ISO / IEC 24759 (waarnaar we zullen verwijzen als FIPS 140-3) en identificeert hoe ze overeenkomen met en verschillen van de secties van de FIPS 140-2-standaard en huidige IG’s . Dit bericht zal zich richten op de eerste drie secties van FIPS 140-2 en gerelateerde IG’s, en de ISO / IEC 19790 secties 7.2-7.4, namelijk de Cryptografische Module Specificatie, Cryptografische Module Interfaces en Rollen, en de Services en Authenticatie secties respectievelijk.

Specificatie cryptografische module

Typen cryptografische modules / cryptografische grens

De FIPS 140-2-standaard (uitgegeven in 2001) is oorspronkelijk geschreven met het idee dat alle modules waren hardwaremodules. Pas later werden in de IG verschillende soorten modules (hybride, software en firmware) toegevoegd en gedefinieerd (IGs 1.9, 1.16 en 1.17). Bovendien beperkte FIPS 140-2 IG 1.9 hybride modules tot een FIPS 140-2 Level 1 validatie.

FIPS 140-3 zal de hardwaremodule, firmwaremodule, softwaremodule, hybride softwaremodule en hybride-firmwaremodule. Het definieert expliciet elk type module in sectie 7.2.2 van de norm. Er is ook geen beperking op het niveau waarop een hybride module in de nieuwe standaard kan worden gevalideerd. Dit is geweldig nieuws voor leveranciers met hybride modules die gevalideerd willen worden op een hoger niveau dan niveau 1!

Bedrijfsmodi

Twee nieuwe termen; “Normale werking” en “Gestoorde werking” zijn geïntroduceerd in FIPS 140-3 19790 en vermeld in de voorgaande blog.

Normale werking is waar de volledige functionaliteit van een cryptografische module beschikbaar en / of configureerbaar is, dwz alle algoritmen, beveiligingsfuncties en services.

Gedegradeerde werking is waar een subset van de functionaliteit beschikbaar en / of configureerbaar is als resultaat van herconfiguratie vanuit een foutstatus.

Als een module een gedegradeerde werking ondersteunt, dan is de gedegradeerde De werkingsmodus kan alleen worden geopend als de module een foutstatus verlaat. Wat betekent dat? Een mechanisme of functie is mislukt en de module is in de foutstatus gekomen en geeft een foutindicator weer. Eenmaal in een fouttoestand kan de module die deze verslechterde werking ondersteunt, overschakelen naar een verslechterde werkingsmodus en verder werken met verminderde mogelijkheden. Hier zijn een paar aanvullende vereisten die u in gedachten moet houden wanneer u uw modules voorbereidt op de nieuwe standaard. De module moet statusinformatie verstrekken wanneer de verslechterde operationele modus wordt geactiveerd, de functie die mislukt moet worden geïsoleerd, alle voorwaardelijke zelftests moeten worden uitgevoerd, voordat een cryptografische functie in de verslechterde modus wordt gebruikt, en last but not least, als er een poging is, terwijl u zich in de verslechterde bedrijfsmodus bevindt, om een niet-operationeel algoritme, beveiligingsfunctie of proces te gebruiken; de diensten moeten aangeven dat een dergelijke poging is gedaan.

Hier is nog een opmerking over de gestoorde werking zoals vermeld in FIPS 140-3. De laatste zin in paragraaf 7.2.4.3 luidt: “Als de module de pre-operationele zelftests niet doorstaat, zal de module niet in gestoord bedrijf gaan werken.” Nou, wacht, zegt u, ik dacht dat de verslechterde werking zou worden gebruikt als iets zoals een zelftest mislukt, maar hier zegt het dat je deze niet kunt invoeren? Onthoud dat je de verslechterde modus alleen kunt openen vanuit een foutstatus. , moet de module eerst de foutstatus ingaan en dan de gedegradeerde werking invoeren, terwijl hij ook voldoet aan de andere vereisten zoals hierboven besproken.

Aanvullende concepten

Houd de SP in de gaten 800-140 documenten die CMVP de komende maanden zal vrijgeven om te zien of de IG’s van FIPS 140-2 die niet werden behandeld in de ISO 19790: 2012 / ISO 24759: 2014-norm, worden behandeld in een van de speciale publicaties. sectie één kan worden opgenomen in een webgebaseerde CMVP-beheerhandleiding, terwijl andere nog steeds worden aangesproken als IG’s.

Cryptografische module-interfaces

De vorige blog ging over de soorten interfaces geïntroduceerd in het ISO-document (HMI: Hardware Module Interface, SFMI: Software of Firmware Module Interface, HSMI : Hybrid Software Module Interface of HFMI: Hybrid Firmware Module Interface), dus die gaan we op dit moment niet bespreken. In plaats daarvan gaan we de invoer- en uitvoerinterfaces aanraken.

Traditionele en nieuwe interfaces

De FIPS 140-2 en FIPS 140-3 bevatten beide: de vier logische interfacegegevensinvoer, gegevensuitvoer, besturingsinvoer en statusuitvoer. FIPS 140-3 introduceert een vijfde interface, de besturingsuitgangsinterface. Een besturingsuitgangsinterface wordt gebruikt voor de uitvoer van opdrachten. Signalen en besturingsgegevens worden gebruikt om de bedrijfsstatus te regelen of aan te geven. Deze besturingsoutput kan informatie zijn die naar een andere cryptografische module wordt gestuurd. De voedingsinterface is ook een interface die vereist is voor alle softwaremodules, behalve voor de softwaremodules.

Trusted Channel

Een ander concept geïntroduceerd in de FIPS 140-3 is dat van een “vertrouwd kanaal” dat is vergelijkbaar met het FIPS 140-2-concept van een “vertrouwd pad” (Sectie 4.7.4 en IG 2.1). Het is een beveiligde communicatieverbinding tussen de cryptografische module en het eindpuntapparaat dat gegevens verzendt naar en gegevens ontvangt van de module, met als doel onbeschermde CSP’s te beveiligen.

Vergelijkbaar met de FIPS 140-2 IG 2.1, zijn er geen vereisten voor het gebruik van een vertrouwd kanaal voor beveiligingsniveaus 1 en 2 in FIPS 140-3. FIPS 140-3 heeft verschillende vereisten voor beveiligingsniveaus 3 en 4, zoals: onbeschermde CSP’s in platte tekst, sleutelcomponenten en authenticatiegegevens, die een vertrouwd kanaal moeten gebruiken wanneer ze worden verzonden tussen de module en een afzender / ontvanger. Het vertrouwde kanaal moet ongeautoriseerde wijziging, vervanging en openbaarmaking voorkomen. Services die een vertrouwd kanaal gebruiken, moeten identiteitsgebaseerde authenticatie gebruiken, en de module moet een statusindicator geven wanneer het vertrouwde kanaal wordt gebruikt.

FIPS 140-3 stelt een extra vereiste voor een module die een vertrouwd kanaal gebruikt op beveiligingsniveau 4 dat we niet zagen in de vorige FIPS 140-2 of IG 2.1. Een Level 4-module die een vertrouwd kanaal gebruikt, moet multi-factor identiteitsgebaseerde authenticatie gebruiken voor alle services die het vertrouwde kanaal gebruiken.

Rollen, services en authenticatie

Rollen

De FIPS 140-2-standaard (paragraaf 4.3.1) vereist dat een module zowel een crypto-officiersrol als een gebruikersrol ondersteunt, en dat de ondersteuning van een onderhoudsrol optioneel was. FIPS 140-3 heeft nog steeds dezelfde drie rollen, maar alleen de rol van crypto-officier is vereist (paragraaf 7.4.2). De gebruikersrol en de onderhoudsrol zijn nu optioneel.

Services

Vereiste services

Er zijn drie vereiste services in de FIPS 140-2-standaard: show status , zelftests uitvoeren en een goedgekeurde beveiligingsfunctie uitvoeren (paragraaf 4.3.2). Dezelfde drie services zijn vereist in FIPS 140-3, naast twee aanvullende vereiste services: informatie over versiebeheer van modules weergeven en nulstelling uitvoeren (paragraaf 7.4.3.1). De “versie-informatie van de module weergeven” vereist dat de cryptografische module de modulenaam / -identificatie en versie-informatie uitvoert, die kan worden geverifieerd aan de hand van een validatiecertificaat. De specificaties van de zeroization-service zijn gedefinieerd in paragraaf 7.9.7 en worden behandeld in een toekomstige blog.

Bypass-service

Zowel FIPS 140-2 als FIPS 140-3 bevatten de optionele bypass-service. FIPS 140-3 roept specifiek op dat een operator die een bypass kan configureren capaciteit in de module moet een geautoriseerde rol aannemen. Hoewel de FIPS 140-2-standaard die vereiste niet specifiek vermeldde, was de meeste veronderstelde authenticatie voor een geautoriseerde rol nodig, aangezien de service kon worden gebruikt, CSP’s vrijgeven en / de beveiliging van de beschermde door de module (IG 3.1).

Zelf-geïnitieerde cryptografische output

Een nieuwe mogelijkheid, behandeld in FIPS 140-3, is de “Self-Initiated Cryptographic Output Capability.” Hier kan de module cryptografische bewerkingen of andere goedgekeurde beveiligingsfuncties uitvoeren zonder tussenkomst van een operator. De crypto-officier kan deze mogelijkheid configureren, terwijl deze configuratie mogelijk blijft tijdens het opnieuw opstarten. Er zijn twee interne acties nodig om de service te activeren en de module moet aangeven dat de service is geactiveerd.

Software / firmware laden

Software / firmware laden wordt geadresseerd in de FIPS 140-2 standaard, en in IG 9.7, in het kader van de vereiste zelftest bij het laden van software / firmware. FIPS 140-2 behandelt het niet als een service zoals we zien in FIPS 140-3 (paragraaf 7.4.3.4). Enkele van de vereisten die in het document worden vermeld, omvatten dat, wil de module een gevalideerde module blijven, alle software / firmware die wordt geladen, moet worden gevalideerd door een validatieautoriteit. Hier moet alle gegevensuitvoer worden geblokkeerd totdat de software / firmware met succes is voltooid; de software / firmware-laadtest moet worden uitgevoerd voordat de code wordt uitgevoerd; de module zal de geladen code niet uitvoeren totdat de pre-operationele zelftests met succes zijn uitgevoerd en, last but not least, de versie-informatie van de modules moet worden bijgewerkt om de toevoeging / update van de software / firmware weer te geven.

Aanvullende opmerking

Niet-geverifieerde services worden niet expliciet behandeld in FIPS 140-3, dus we zullen moeten zien of dit concept, dat wordt behandeld in de huidige IG 3.1, wordt overgedragen in een van de SP800-140-documenten. Meer hierover zal in toekomstige blogs aan de orde komen.

Authenticatie

FIPS 140-3 is vergelijkbaar met FIPS 140-2 voor authenticatie op beveiligingsniveaus 1-3: (ISO 19790: Level 1 – geen authenticatievereisten; niveau 2 – minimale op rollen gebaseerde authenticatie; niveau 3 – op identiteit gebaseerde authenticatie). Het grootste verschil is dat voor niveau 2 de toevoeging van het woord “minimum” is toegevoegd, wat overeenkomt met de verduidelijking die wordt behandeld in IG 3.4. Niveau 4-authenticatie, in de ISO-gebaseerde FIPS 140-3-standaard, neemt authenticatie over een niveau, door niet alleen identiteitsgebaseerde authenticatie te vereisen. Voor authenticatie op niveau 4 moet het multi-factor identiteitsgebaseerd zijn.

Een paar aanvullende punten om op te merken in deze sectie is dat FIPS 140-2 gespecificeerd de sterkte van authenticatie vereist door de module. De sterkte is niet gedefinieerd in FIPS 140-3, maar moet worden gespecificeerd in het modulebeveiligingsbeleid. Hoogstwaarschijnlijk zal elke validatie-autoriteit een authenticatiesterkte opnemen in hun aanvullende documentatie.

Goedgekeurde authenticatiemechanismen kunnen niet worden geïmplementeerd door gedocumenteerde procedures of beveiligingsregels (bijv. beleid). Dit betekent dat beperkingen voor de wachtwoordgrootte moeten worden geconfigureerd en afgedwongen door de module. Dit kan van invloed zijn op de manier waarop verschillende van de huidige modules werken. , houd hier rekening mee terwijl u uw modules voorbereidt op ISO-vereisten.

In het kort

Er valt veel te leren over de verschillen tussen FIPS 140-2 en FIPS 140-3. Hoewel er een groot aantal overeenkomsten zijn, zijn er ook nogal wat veranderingen. Onze serie over dit onderwerp gaat verder, waarbij we bij elke post een nieuw gebied behandelen. Als u vragen heeft, kunt u zoals altijd rechtstreeks contact met ons opnemen. Ons team staat altijd klaar om te helpen.