sanotaan, että HMAC-SHA1: n turvallisuus ei riipu törmäysten vastustamisesta? Sanovatko he nimenomaan HOTP: n tai HMAC-SHA1: n suhteen mihin tahansa käyttöön?
Jos HMAC-SHA1: ää käytetään asiakirjan eheyden tarkistamiseen ja löydät törmäyksen, voit tehdä muutoksia asiakirjaan, eikö?
http://tools.ietf.org/html/rfc2104#section-6
Jopa RFC: n mukaan vastustuskyky törmäyksille on merkityksellinen
Tässä esitetyn viestin todennusmekanismin turvallisuus riippuu hash-funktion H salaustoiminnoista: vastustuskyky törmäyksen löytämiselle (rajoitettu tapaukseen, jossa alkuarvo on salainen ja satunnainen ja jossa toiminnon lähtö ei ole nimenomaisesti hyökkääjän käytettävissä), ja H: n pakkausfunktion sanotodennusominaisuus, kun sitä käytetään yksittäisiin lohkoihin
Mitä puuttuu täällä?
Kommentit
- Kysymyksessä näyttää olevan sekaannusta: HMAC-SHA1: ää ei käytetä asiakirjan allekirjoittamiseen (ainakaan ei yleensä; ja olettaen sen olevan oli, HMAC: n vakioletus, että sen avainsyöttö on salaa, ei voi ' olla voimassa allekirjoituksen todentamismenettely on julkinen). Minusta tämä vastaus on varsin hieno.
- @fgrieu – luulen, että tein virheen terminologiassa – kirjoittaessani allekirjoitusta minun olisi pitänyt oikeastaan kirjoitettu luomalla viestin todennuksen tiivistelmä eheyden suojaamiseksi. Törmäysten sattuessa voit vaihtaa viestin ja säilyttää saman MAC: n, joten se on ongelma, eikö?
- Pitäisikö meidän sulkea tämä kopiona Pidetäänkö HMAC-MD5: tä turvallisena salattujen tietojen todennuksessa? ? Vaikka tämä kysymys koskee SHA1: tä, ei MD5: tä, vastaus on melkein sama.
- Olen ' olen melko varma, onko minulla ennen kuvaa hyökkäys SHA: ta vastaan -1 tämä räjähtää.
vastaus
Tämän vastauksen ensimmäisessä osassa ”oletan, että kautta paremmin laitteisto- tai algoritmisista parannuksista on tullut rutiininomaisesti mahdollista näyttää törmäys SHA-1: lle samanlaisella menetelmällä kuin Xiaoyun Wang, Yiqun Lisa Yin ja Hongbo Yu ” hyökkäys tai Marc Stevensin hyökkäys . Tämä on saavutettu julkisesti alkuvuodesta 2017, ja se oli ollut selvästi toteutettavissa (ponnistelut edustavat vain tunteja bitcoinin louhintaan käytettyä hajautusta ; mutta siihen käytetty laitteisto ei voi ” SHA-1: n hyökkäystä varten.
Päinvastoin kuin kysymyksessä katsotaan, hyökkääjä ei salli ei kota HMAC-SHA-1-avain tehdä huomaamaton muutos asiakirjaan; mukaan lukien, jos hyökkääjä pystyy valmistelemaan asiakirjan, hän on halukas myöhemmin muuttamaan.
Yksi selitys on, että harkitsemamme SHA-1: n törmäyshyökkäykset edellyttävät tietoa tilasta SHA-1-ketjutusmuuttuja ja HMAC: n hyökkääjä, joka ei tiedä avainta, riistetään tuosta tiedosta avaimella, joka syöttää molempiin päihin kierrosten iteroinnin, joissa viesti seisoo HMAC: ssä. HMAC: n rikkomiseen tarvitaan paljon syvempi SHA-1: n pyöreän toiminnon katkaisu. Ei sattumalta, M. Bellare ”s NMAC: n ja HMAC: n uudet todisteet: suojaus ilman törmäysresistanssia osoittaa, että HMAC: n tietoturva edellyttää, että sen pyöreässä toiminnossa on vain heikompia ominaisuuksia kuin mitä tarvitaan vastaavan hashin törmäysvastukseen.
Mikä olisi mahdollista, on hyökkääjä tietäen HMAC-avaimen valmistellakseen asiakirjan, jota hän haluaa myöhemmin muuttaa ja jota voidaan muuttaa muuttamatta MAC: ää. Mutta koska hyökkääjällä on HMAC-avain, sitä ei pidetä HMAC-taukona.
kommentti kysyy milloin SHA-1: tä ei tule käyttää?
SHA-1 on suositeltavaa poistaa käytöstä nopeasti törmäyksenkestävyyttä vaativissa sovelluksissa (kuvana: kävele nopeasti pois, kun poistut rakennus, jossa palohälytys soi, kun savua ei ole). Tähän sisältyy muiden valmistajien edes osittain valmistamien asiakirjojen (eli useimpien asiakirjojen) eheystarkistuksen tai digitaalisen allekirjoituksen hajauttaminen. Jos SHA-1: n käytön jatkamisella on merkittäviä toiminnallisia etuja, siitä voidaan turvallisesti tehdä poikkeus lisäämällä vastustajille jotain arvaamatonta ennen mitä tahansa viestin osaa, johon vastustaja voi vaikuttaa.Esimerkiksi pakottamalla ennalta arvaamaton varmenteen sarjanumero varmenteen pyytämisen yhteydessä varmentaja voi silti turvallisesti antaa SHA-1-varmenteita sisäiseen allekirjoitukseensa.
Kuten tämän osan ensimmäisessä osassa selitetään Vastaus, niin kauan kuin HMAC-SHA-1: n avain oletetaan salaiseksi, ei ole mitään viitteitä siitä, että HMAC-SHA-1 olisi epävarma, koska se käyttää SHA-1: tä. Jos avaimen oletetaan olevan julkinen tai sen vuotoa pidetään toimintamahdollisuutena, jossa HMAC: lle halutaan edelleen törmäyskestävyys, myös avaimen paljastamisen jälkeen valmistelluille viesteille, sovelletaan edellisessä kappaleessa käsiteltyjä varotoimia.
Kommentit
- Joten milloin SHA1: ää ei tulisi käyttää? ts. ongelman löytäminen SHA1: ssä estää sen käyttämisen missä?
- Se ' suositteli yleensä siirtymistä pois (" walk ", ei " run ") SHA-1: stä. HMAC-SHA1: n spesifistä rakennetta pidetään silti turvallisena käyttää (olettaen salaisen avaimen) HMAC: n turvallisuustodistuksen takia, joka ei perustu taustalla olevan PRF: n törmäysvastukseen. Jos olet epävarma, siirry SHA-2: een.
- @StephenTouset – joo, sain sen. Onko kuitenkin SHA-1: n käyttöä, josta sinun pitäisi karata pois eikä siirtyä pois tai kävellä pois.
- Ei, muuten se olisi neuvo. SHA-1: n ' törmäysvastus rikkoutuu vain teoreettisessa mielessä juuri nyt. Tunnettuja törmäyksiä ei ole vielä löydetty, vaikka nykyinen paras hyökkäys onkin vain toteutettavuuden rajalla.
Vastaa
Kun ihmiset sanovat, että HMAC-MD5 tai HMAC-SHA1 ovat edelleen suojattuja, he tarkoittavat, että ne ovat edelleen suojattuja PRF: nä ja MAC: nä.
Tärkein oletus on, että hyökkääjä ei tunne avainta.
$$ \ mathrm {HMAC} = \ mathrm {hash} (k_2 | \ mathrm {hash} (k_1 | m)) $$
-
Potentiaalisuus hyökkäys 1: Löydä yleinen törmäys, joka on voimassa monille avaimille:
HMAC: ää käytettäessä viesti ei hajaudu suoraan, mutta sen etuliitteenä on $ k_1 $. Tämä tarkoittaa, että hyökkääjä ei ” en tiedä tiivisteen sisäistä tilaa, kun viesti alkaa. Useimmissa vaihtoehdoissa törmäävän viestin löytäminen on $ k_1 $, mikä on erittäin vaikeaa 1 .
-
Mahdollinen hyökkäys 2: palauta avain
Tämän onnistumiseksi hash-toiminto vaatii paljon suurempia taukoja kuin pelkät törmäykset. Se muistuttaa ensimmäistä kuvaa edeltävää hyökkäystä, ominaisuutta, joka on edelleen vahva sekä MD5: lle että SHA1: lle.
Toisaalta, jos käytit hyökkääjän tuntemaa avainta ja hyökkääjällä on kyky löytää törmäyksiä taustalla olevasta hashista (mielivaltaisille IV: lle), nämä kääntyvät HMAC: n törmäyksiin. Joten jos tarvitset suojausta avaamattomassa tilanteessa, käytä törmäyksenkestävää tiivistettä, kuten SHA2, ja harkitse, ettet käytä HMAC: ää lainkaan.
1 Epäilen, että se ei ole mahdollista (realistisille viestikokoille) jopa laskennallisesti rajoittamattomille hyökkääjille, mutta sen osoittaminen on vaikeaa.
Kommentit
- Joten milloin SHA1: ää ei tulisi käyttää? ts. ongelman löytäminen SHA1: ssä estää sen käytön missä?
- @ user93353 Kuten sanoin, HMAC-SHA1: n turvallisuus riippuu tuntemattomasta avaimesta. Jos avainta ei ole tai hyökkääjä tietää sen , SHA1: n törmäyksistä tulee uhka. Mutta SHA1: tä tulisi harvoin, jos koskaan, käyttää uusissa malleissa, koska käytettävissä on parempia vaihtoehtoja.
- Jos hyökkääjä tietää avaimen, jopa SHA2 olla ongelma, eikö?
- @ user93353 Riippuu siitä, mitä haluat saavuttaa. Tietenkään mikään avaamaton hash ei ole MAC.
- @CodesInChaos – sanot, että HMAC-SHA1 on ongelma vain, jos avain on tiedossa, mutta jos avain on tiedetään, että siitä tulee ongelma kaikissa HMAC-hash-operaatioissa, eikö?