Hvorfor anses HMAC-SHA1 fortsatt som sikker?

I den første delen av dette svaret vil jeg anta at gjennom bedre maskinvare eller / og algoritmiske forbedringer, har det blitt rutinemessig mulig å utvise en kollisjon for SHA-1 ved en metode som ligner den på Xiaoyun Wang, Yiqun Lisa Yin og Hongbo Yu » s angrep , eller Marc Stevens s angrep . Dette er oppnådd offentlig i begynnelsen av 2017, og hadde vært tydelig gjennomførbar (innsatsen representerer bare timer med hashing-innsats brukt på bitcoin mining , men maskinvaren som brukes til det kan ikke bli omlagt for angrepet på SHA-1).

I motsetning til hva som blir vurdert i spørsmålet, ville det ikke tillate en angriper ikke kowing HMAC-SHA-1-nøkkelen for å gjøre en uoppdaget endring i et dokument; at «inkludert hvis angriperen er i stand til å forberede dokumentet han / hun er villig til senere å endre.

En forklaring er at kollisjonsangrepene på SHA-1 vi vurderer krever kunnskap om tilstanden til SHA-1-kjedevariabelen, og angriperen av HMAC som ikke kjenner nøkkelen, blir fratatt den kunnskapen ved at nøkkelen går inn i begge ekstremiteter av iterasjonen av runder der meldingen står i HMAC. En mye dypere pause i SHA-1 «s runde funksjon ville være nødvendig for å bryte HMAC. Ikke tilfeldig, M. Bellare» s Nye bevis for NMAC og HMAC: sikkerhet uten kollisjonsmotstand viser at sikkerheten til HMAC holder forutsatt at bare svakere egenskaper på sin runde funksjon er nødvendig enn kollisjonsmotstanden til den tilsvarende hasjen.

Det som er mulig er for en angriper kjenner HMAC-nøkkelen for å utarbeide et dokument som han / hun er villig til senere å endre, som kan endres uten å endre MAC. Men siden angriperen holder HMAC-nøkkelen, blir det ikke ansett som et brudd på HMAC.

En kommentar spør når bør SHA-1 ikke brukes?

Det anbefales å raskt fase ut SHA-1 i applikasjoner som krever kollisjonsmotstand (som et bilde: gå raskt bort når du går ut en bygning som brannalarm ringer når det ikke er røyk). Det inkluderer hashing for integritetskontroll eller digital signatur av dokumenter utarbeidet av andre selv delvis (som er de fleste dokumenter). Hvis fortsatt bruk av SHA-1 har sterke operasjonelle fordeler, kan det trygt gjøres et unntak ved å sette inn noe uforutsigbart av motstandere før noen del av meldingen som en motstander kan påvirke.For eksempel ved å håndheve et uforutsigbart sertifikatens serienummer på tidspunktet for forespørsel om et sertifikat, kan en sertifiseringsmyndighet fremdeles trygt utstede sertifikater ved bruk av SHA-1 for deres interne signatur.

Som forklart i første del av dette svar så lenge nøkkelen til HMAC-SHA-1 antas hemmelig, er det ingen indikasjoner på at HMAC-SHA-1 er usikker fordi den bruker SHA-1. Hvis nøkkelen antas å være offentlig, eller hvis lekkasjen blir ansett som en operativ mulighet der det fremdeles er ønsket kollisjonsmotstand for HMAC, inkludert for meldinger utarbeidet etter avsløring av nøkkelen, gjelder forholdsregler som er diskutert i forrige avsnitt.

Kommentarer

• Så når skal SHA1 ikke brukes? dvs. oppdagelse av problemet i SHA1 utelukker det fra bruk hvor?
• Det ' anbefales generelt å flytte bort (" gå ", ikke " kjør ") fra SHA-1. Når det er sagt, anses den spesifikke konstruksjonen av HMAC-SHA1 fortsatt å være trygg å bruke (forutsatt en hemmelig nøkkel) på grunn av sikkerhetsbeviset for HMAC som ikke er avhengig av kollisjonsmotstand fra den underliggende PRF. Når du er i tvil, flytt til SHA-2.
• @StephenTouset – ja, jeg har det. Imidlertid er det noen bruk av SHA-1 som du burde stikker av i stedet for å flytte bort eller gå bort.
• Nei, ellers ville det være rådet. SHA-1 ' s kollisjonsmotstand er bare ødelagt i teoretisk forstand akkurat nå. Ingen kjente kollisjoner har ennå blitt funnet, selv om det nåværende beste angrepet bare er på kanten av gjennomførbarhet.

Når folk sier at HMAC-MD5 eller HMAC-SHA1 fremdeles er sikre, mener de at de fortsatt er sikre som PRF og MAC.

Nøkkelforutsetningen her er at nøkkelen er ukjent for angriperen.

$$ \ mathrm {HMAC} = \ mathrm {hash} (k_2 | \ mathrm {hash} (k_1 | m)) $$

• Potensiell angrep 1: Finn en universell kollisjon som er gyldig for mange nøkler:

  Ved å bruke HMAC blir ikke meldingen hash direkte, men den har $ k_1 $ som prefiks. Dette betyr at angriperen ikke » ikke vite den interne tilstanden til hasjen når meldingen starter. Å finne en melding som kolliderer for de fleste valg er $ k_1 $ er ekstremt vanskelig ¹ .

• Potensielt angrep 2: Gjenopprett nøkkelen

  For at dette skal lykkes, trenger hash-funksjonen mye større pauser enn bare kollisjoner. Det ligner på et første pre-image-angrep, en eiendom som fortsatt er sterk for både MD5 og SHA1.

På den annen side, hvis du brukte en nøkkel kjent for angriperen og angriperen har muligheten til å finne kollisjoner i den underliggende hasjen (for vilkårlig IV), blir disse i kollisjoner av HMAC. Så hvis du trenger sikkerhet i et scenario som ikke er tastet, kan du bruke en kollisjonsbestandig hash, som SHA2, og vurdere å ikke bruke HMAC i det hele tatt.

¹ Jeg mistenker at det ikke er mulig (for realistiske meldingsstørrelser) selv for beregningsmessig ubegrensede angripere, men det er vanskelig å bevise det.

Kommentarer

• Så når skal SHA1 ikke brukes? dvs. oppdagelse av problemet i SHA1 utelukker det fra bruk hvor?
• @ user93353 Som jeg sa, avhenger sikkerheten til HMAC-SHA1 av den ukjente nøkkelen. Hvis det ikke er noen nøkkel eller den er kjent for angriperen , kollisjonene i SHA1 blir en trussel. Men SHA1 bør sjelden, om noen gang, brukes i nye design, siden det er bedre alternativer tilgjengelig.
• Hvis nøkkelen er kjent for angriperen, vil til og med SHA2 være et problem, ikke sant?
• @ user93353 Avhenger av hva du vil oppnå. Selvfølgelig er ingen hash uten tastatur en MAC.
• @CodesInChaos – du sier at HMAC-SHA1 er en problemet bare hvis nøkkelen er kjent. Men hvis nøkkelen er kjent, det vil være et problem for enhver HMAC-hash-operasjon, ikke sant?