Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Компьютерлік байланыс хэш алгоритмі
Computer communications hash algorithm
Криптографияда HMAC (кейде кілті бар хабарламаны аутентификациялау коды немесе хэш негізделген хабарламаны аутентификациялау коды деп толықтырылады) – криптографиялық хэш функциясы және құпия криптографиялық кілтті қолданатын хабарламаны аутентификациялау кодының (MAC) нақты түрі. Кез келген MAC сияқты, ол хабарламаның деректерінің бүтіндігі мен нақтылығын бірдей тексеру үшін қолданылуы мүмкін. HMAC – кілтті қолданатын хэш функциясының бір түрі, оны кілт алу схемасында немесе кілт созу схемасында да пайдалануға болады. HMAC асимметриялық криптографиямен цифрлық қолтаңбаларды пайдаланудың орнына ортақ құпияны қолдану арқылы аутентификацияны қамтамасыз ете алады. Бұл күрделі ашық кілт инфрақұрылымының қажеттілігін жояды, себебі кілт алмасуын байланыс жасайтын тараптар жүзеге асырады, олар кілтті келісу үшін сенімді арнаны орнатуға және пайдалануға жауапты.
In cryptography, an HMAC (sometimes expanded as either keyed hash message authentication code or hash based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and authenticity of a message. An HMAC is a type of keyed hash function that can also be used in a key derivation scheme or a key stretching scheme. HMAC can provide authentication using a shared secret instead of using digital signatures with asymmetric cryptography. It trades off the need for a complex public key infrastructure by delegating the key exchange to the communicating parties, who are responsible for establishing and using a trusted channel to agree on the key prior to communication.
Құрылыс қағидалары
HMAC спецификациясының дизайны кілтті хэш-функциямен біріктірудің қарапайым механизмдеріне жасалған шабуылдардың болуымен негізделген. Мысалы, HMAC қамтамасыз ететін қауіпсіздікті MAC = H(кілт ∥ хабарлама) арқылы қол жеткізуге болады деп болжауға болады. Алайда, бұл әдіс үлкен кемшілікке ұшырайды: көптеген хэш-функциялар үшін кілтті білмей хабарламаға деректерді қосып, басқа жарамды MAC ("ұзындығын кеңейту шабуылы") алу оңай. Балама ретінде, MAC = H(хабарлама ∥ кілт) кілтін қосу (алып қою), (кілтсіз) хэш-функциясында соқтығысуды таба алатын шабуылшы MAC-те соқтығысуға себеп болады (екі хабарлама m1 және m2 бірдей хэшті беретін болса, қосылған кілт хэштелгенге дейін хэш-функцияға бірдей бастапқы жағдайды береді, сондықтан соңғы хэш бірдей болады). MAC = H(кілт ∥ хабарлама ∥ кілт) пайдалану жақсырақ, бірақ әртүрлі қауіпсіздік мақалалары екі түрлі кілт қолданылған кезде де осы тәсілдің осалдықтарын көрсеткен. Қазіргі HMAC спецификациясына қарсы белгілі кеңейту шабуылдары табылмады, ол H(кілт ∥ H(кілт ∥ хабарлама)) деп анықталған, өйткені хэш функциясын сырттан қолдану ішкі хэштің аралық нәтижесін жасырады. Ipad және opad мәндері алгоритмнің қауіпсіздігі үшін маңызды емес, бірақ бір-бірінен үлкен Хамминг қашықтығына ие болу үшін анықталды, сондықтан ішкі және сыртқы кілттерде ортақ биттердің саны азаяды. HMAC-тің қауіпсіздігін төмендетуі олардың кем дегенде бір битке өзгеше болуын қажет етеді. NIST SHA 3 конкурсының жеңімпазы ретінде таңдалған Keccak хэш функциясы осы ұялы тәсілді қажет етпейді және оны хабарламаның басына кілтті қосып MAC құру үшін қолдануға болады, өйткені ол ұзындығын кеңейту шабуылдарына осал емес.
The design of the HMAC specification was motivated by the existence of attacks on more trivial mechanisms for combining a key with a hash function. For example, one might assume the same security that HMAC provides could be achieved with MAC = H(key ∥ message). However, this method suffers from a serious flaw: with most hash functions, it is easy to append data to the message without knowing the key and obtain another valid MAC ("length extension attack"). The alternative, appending the key using MAC = H(message ∥ key), suffers from the problem that an attacker who can find a collision in the (unkeyed) hash function has a collision in the MAC (as two messages m1 and m2 yielding the same hash will provide the same start condition to the hash function before the appended key is hashed, hence the final hash will be the same). Using MAC = H(key ∥ message ∥ key) is better, but various security papers have suggested vulnerabilities with this approach, even when two different keys are used. No known extension attacks have been found against the current HMAC specification which is defined as H(key ∥ H(key ∥ message)) because the outer application of the hash function masks the intermediate result of the internal hash. The values of ipad and opad are not critical to the security of the algorithm, but were defined in such a way to have a large Hamming distance from each other and so the inner and outer keys will have fewer bits in common. The security reduction of HMAC does require them to be different in at least one bit. The Keccak hash function, that was selected by NIST as the SHA 3 competition winner, doesn't need this nested approach and can be used to generate a MAC by simply prepending the key to the message, as it is not susceptible to length extension attacks.
Қауіпсіздік
HMAC-тің криптографиялық беріктігі қолданылатын құпия кілтінің мөлшеріне және қолданылатын негізгі хэш-функцияның қауіпсіздігіне байланысты. HMAC құрылымының қауіпсіздігі қолданылған хэш-функцияның қауіпсіздік қасиеттеріне тікелей байланысты екені дәлелденді. HMAC-қа қарсы ең көп таралған шабуыл – құпия кілтті ашу үшін күш қолдану. HMAC-тер өздерінің негізгі хэштеу алгоритмдеріне қарағанда соқтығысуларға (коллизияларға) әлдеқайда аз сезімтал. Атап айтқанда, Михир Белларе HMAC псевдорандомдық функция (PRF) екенін дәлелдеді, бұл қысым функциясы PRF болған жағдайда ғана дұрыс. Сондықтан HMAC MD5, MD5-те табылған әлсіздіктерге ұшырамайды. RFC 2104 талап етеді, "B байттан ұзын кілттер алдымен H арқылы хэштелді", бұл шатастыратын жалған соқтығысуға (псевдоколлизияға) әкеледі: егер кілт хэш блогының мөлшерінен ұзын болса (мысалы, SHA 1 үшін 64 байт), онда HMAC(k, m) есептелуі тиіс HMAC(H(k), m) ретінде. Бұл қасиет кейде парольді хэштеу сценарийлерінде HMAC-тің әлсіздігі ретінде қарастырылады: ұзын ASCII жолы мен кездейсоқ мәнді табу мүмкін, олардың хэштері де ASCII жолы болады, және екі мән де бірдей HMAC нәтижесін береді. 2006 жылы Джонгсун Ким, Алекс Бирюков, Барт Пренел және Сёкхие Хонг, MD5 және SHA 1-дің қысқартылған нұсқаларымен немесе HAVAL, MD4 және SHA 0-дің толық нұсқаларымен HMAC-ты кездейсоқ функциядан немесе кездейсоқ функциялы HMAC-тан қалай ажыратуға болатынын көрсетті. Дифференциалдық ажыратушылар шабуылшыға HMAC-қа қарсы жалған шабуыл жасауға мүмкіндік береді. Сонымен қатар, дифференциалдық және тіктөртбұрышты ажыратушылар екінші преобразды шабуылдарға әкелуі мүмкін. MD4-тің толық нұсқасы бар HMAC осы біліммен жасалуы мүмкін. Бұл шабуылдар HMAC-тің қауіпсіздік дәлеліне қайшы келмейді, бірақ қолданыстағы криптографиялық хэш-функцияларға негізделген HMAC-ты түсінуге көмектеседі. 2009 жылы Xiaoyun Wang және басқалар, HMAC MD5-ке байланысты кілттерді пайдаланбай, ерекше шабуыл жасауды ұсынды. Ол HMAC-тің MD5 инстанциясын 297 сұраныспен 0.87 ықтималдықпен кездейсоқ функциямен инстанцияланған нұсқадан ажырата алады. 2011 жылы MD5 және HMAC MD5 қауіпсіздік мәселелерін қорытындылау үшін ақпараттық RFC 6151 жарияланды. HMAC MD5 үшін RFC қорытындылайды, MD5 хэш-функциясының қауіпсіздігі қатты зардап шеккенімен, қазіргі кезде белгілі "HMAC MD5-ке жасалған шабуылдар хабарламаны аутентификациялау коды ретінде қолданғанда практикалық осалдықты көрсетпейді", бірақ ол "жаңа протокол дизайны үшін HMAC MD5 шифр жиынтығын қосуға болмайды" деп қосады.
The cryptographic strength of the HMAC depends upon the size of the secret key that is used and the security of the underlying hash function used. It has been proven that the security of an HMAC construction is directly related to security properties of the hash function used. The most common attack against HMACs is brute force to uncover the secret key. HMACs are substantially less affected by collisions than their underlying hashing algorithms alone. In particular, Mihir Bellare proved that HMAC is a pseudo random function (PRF) under the sole assumption that the compression function is a PRF. Therefore, HMAC MD5 does not suffer from the same weaknesses that have been found in MD5. RFC 2104 requires that "keys longer than B bytes are first hashed using H" which leads to a confusing pseudo collision: if the key is longer than the hash block size (e. g. 64 bytes for SHA 1), then HMAC(k, m) is computed as HMAC(H(k), m). This property is sometimes raised as a possible weakness of HMAC in password hashing scenarios: it has been demonstrated that it's possible to find a long ASCII string and a random value whose hash will be also an ASCII string, and both values will produce the same HMAC output. In 2006, Jongsung Kim, Alex Biryukov, Bart Preneel, and Seokhie Hong showed how to distinguish HMAC with reduced versions of MD5 and SHA 1 or full versions of HAVAL, MD4, and SHA 0 from a random function or HMAC with a random function. Differential distinguishers allow an attacker to devise a forgery attack on HMAC. Furthermore, differential and rectangle distinguishers can lead to second preimage attacks. HMAC with the full version of MD4 can be forged with this knowledge. These attacks do not contradict the security proof of HMAC, but provide insight into HMAC based on existing cryptographic hash functions. In 2009, Xiaoyun Wang et al. presented a distinguishing attack on HMAC MD5 without using related keys. It can distinguish an instantiation of HMAC with MD5 from an instantiation with a random function with 297 queries with probability 0.87. In 2011 an informational RFC 6151 was published to summarize security considerations in MD5 and HMAC MD5. For HMAC MD5 the RFC summarizes that – although the security of the MD5 hash function itself is severely compromised – the currently known "attacks on HMAC MD5 do not seem to indicate a practical vulnerability when used as a message authentication code", but it also adds that "for a new protocol design, a ciphersuite with HMAC MD5 should not be included".