ในวิทยาการเข้ารหัสลับHMAC ( บางครั้งอาจขยายความว่ารหัสยืนยันข้อความแบบแฮชที่มีคีย์หรือรหัสยืนยันข้อความแบบแฮช ) เป็น รหัสยืนยันข้อความ (MAC) ประเภทหนึ่งโดยเฉพาะ ซึ่งเกี่ยวข้องกับ ฟังก์ชันแฮชทางวิทยาการเข้ารหัสลับและคีย์เข้ารหัสลับที่เป็นความลับ เช่นเดียวกับ MAC ทั่วไป HMAC สามารถใช้เพื่อตรวจสอบทั้งความสมบูรณ์ของข้อมูลและความถูกต้องของข้อความได้พร้อมกัน HMAC เป็นฟังก์ชันแฮชที่มีคีย์ประเภทหนึ่งที่สามารถใช้ในรูปแบบการสร้างคีย์หรือรูปแบบการขยายคีย์ได้เช่นกัน

HMAC สามารถให้การตรวจสอบความถูกต้องโดยใช้ รหัส ลับร่วมกันแทนการใช้ลายเซ็นดิจิทัลด้วยการเข้ารหัสแบบไม่สมมาตรโดยลดความจำเป็นในการใช้โครงสร้างพื้นฐานกุญแจสาธารณะ ที่ซับซ้อน ด้วยการมอบหมายการแลกเปลี่ยนกุญแจให้กับฝ่ายที่สื่อสารกัน ซึ่งมีหน้าที่รับผิดชอบในการสร้างและใช้ช่องทางที่เชื่อถือได้เพื่อตกลงเกี่ยวกับกุญแจก่อนที่จะทำการสื่อสาร

ฟังก์ชันแฮชเข้ารหัสลับใดๆ เช่นSHA-2หรือSHA-3อาจใช้ในการคำนวณ HMAC ได้ โดยอัลกอริทึม MAC ที่ได้จะเรียกว่า HMAC- xโดยที่xคือฟังก์ชันแฮชที่ใช้ (เช่น HMAC-SHA256 หรือ HMAC-SHA3-512) ความแข็งแกร่งในการเข้ารหัสลับของ HMAC ขึ้นอยู่กับความแข็งแกร่งในการเข้ารหัสลับของฟังก์ชันแฮชพื้นฐาน ขนาดของผลลัพธ์แฮช และขนาดและคุณภาพของคีย์^{[ 1 ]}

HMAC ใช้การคำนวณแฮชสองรอบ ก่อนแต่ละรอบ จะใช้กุญแจลับเพื่อสร้างกุญแจสองชุด คือ กุญแจภายในและกุญแจภายนอก จากนั้น รอบแรกของอัลกอริธึมแฮชจะสร้างแฮชภายในที่ได้จากข้อความและกุญแจภายใน รอบที่สองจะสร้างรหัส HMAC สุดท้ายที่ได้จากผลลัพธ์แฮชภายในและกุญแจภายนอก ดังนั้นอัลกอริธึมนี้จึงมีภูมิคุ้มกันที่ดีกว่าต่อ การ โจมตีแบบขยายความยาว

ฟังก์ชันแฮชแบบวนซ้ำ (ที่ใช้โครงสร้าง Merkle–Damgård ) จะแบ่งข้อความออกเป็นบล็อกขนาดคงที่ และวนซ้ำด้วยฟังก์ชันการบีบอัดตัวอย่างเช่น SHA-256 ทำงานกับบล็อกขนาด 512 บิต ขนาดของผลลัพธ์ของ HMAC จะเท่ากับขนาดของฟังก์ชันแฮชพื้นฐาน (เช่น 256 และ 512 บิตในกรณีของ SHA-256 และ SHA3-512 ตามลำดับ) แม้ว่าจะสามารถตัดทอนได้หากต้องการ

HMAC ไม่ได้เข้ารหัสข้อความ แต่ข้อความ (ไม่ว่าจะเข้ารหัสหรือไม่) จะต้องถูกส่งไปพร้อมกับค่าแฮช HMAC ฝ่ายที่มีกุญแจลับจะทำการแฮชข้อความอีกครั้งด้วยตนเอง และหากเป็นข้อความที่ถูกต้อง ค่าแฮชที่ได้รับและค่าแฮชที่คำนวณได้จะตรงกัน

คำจำกัดความและการวิเคราะห์โครงสร้าง HMAC ได้รับการตีพิมพ์ครั้งแรกในปี 1996 ในบทความโดยMihir Bellare , Ran CanettiและHugo Krawczyk [ ^{1 ] [ 2 ]}และพวกเขายังเขียน RFC 2104 ในปี 1997 ^{[ 3 ] : §2}บทความปี 1996 ยังได้กำหนดรูปแบบซ้อนกันที่เรียกว่า NMAC (Nested MAC) FIPS ^PUB 198ได้สรุปและกำหนดมาตรฐานการใช้ HMAC ^{[ 4 ]} HMAC ถูกใช้ภายใน โปรโตคอล IPsec [ ^{2 ]} SSH ^และ TLSและสำหรับJSON Web Tokens

คำจำกัดความนี้มาจาก RFC 2104:

${\displaystyle {\begin{aligned}\operatorname {HMAC} (K,m)&=\operatorname {H} {\Bigl (}{\bigl (}K'\oplus opad{\bigr )}\parallel \operatorname {H} {\bigl (}\left(K'\oplus ipad\right)\parallel m{\bigr )}{\Bigr )}\\K'&={\begin{cases}\operatorname {H} \left(K\right)&{\text{if}}\ K{\text{ is larger than block size}}\\K&{\text{otherwise}}\end{cases}}\end{aligned}}}$

ที่ไหน

${\displaystyle \operatorname {H} }$เป็นฟังก์ชันแฮชเข้ารหัสลับ

${\displaystyle m}$คือข้อความที่ต้องได้รับการตรวจสอบความถูกต้อง

${\displaystyle K}$คือกุญแจลับ

${\displaystyle K'}$เป็นคีย์ขนาดบล็อกที่ได้มาจากคีย์ลับKโดยอาจทำได้โดยการเติมเลข 0 ทางด้านขวาจนถึงขนาดบล็อก หรือโดยการแฮชให้ได้ค่าที่น้อยกว่าหรือเท่ากับขนาดบล็อกก่อน แล้วจึงเติมเลข 0 ทางด้านขวา

${\displaystyle \parallel }$หมายถึงการต่อกัน

${\displaystyle \oplus }$หมายถึงการดำเนินการเอกซ์ คลูซีฟแบบบิต (XOR)

${\displaystyle opad}$คือส่วนเติมขอบด้านนอกที่มีขนาดเท่ากับบล็อก ซึ่งประกอบด้วยไบต์ที่มีค่า 0x5c ซ้ำกัน

${\displaystyle ipad}$คือการเติมช่องว่างภายในขนาดบล็อก ซึ่งประกอบด้วยไบต์ซ้ำที่มีค่า 0x36 ^{[ 3 ] : §2}

รหัสเทียมต่อไปนี้แสดงให้เห็นว่า HMAC สามารถนำไปใช้ได้อย่างไร ขนาดบล็อกคือ 512 บิต (64 ไบต์) เมื่อใช้ฟังก์ชันแฮชต่อไปนี้: SHA-1, MD5, RIPEMD-128 ^{[ 3 ] : §2}

ฟังก์ชัน hmac รับอินพุตดังนี้: key: ไบต์ // อาร์เรย์ของไบต์ message: ไบต์ // อาร์เรย์ของไบต์ที่จะถูกแฮ ช hash: ฟังก์ชัน// ฟังก์ชันแฮชที่จะใช้ (เช่น SHA-1) blockSize: จำนวนเต็ม // ขนาดบล็อกของฟังก์ชันแฮช (เช่น 64 ไบต์สำหรับ SHA-1)// คำนวณขนาดบล็อกของคีย์ block_sized_key = computeBlockSizedKey(key, hash, blockSize) o_key_pad ← block_sized_key xor [0x5c blockSize] // ปุ่มที่มีขอบด้านนอก i_key_pad ← block_sized_key xor [0x36 blockSize] // ปุ่มที่มีขอบด้านในส่งคืนค่าแฮช (o_key_pad ∥) และค่าแฮช (i_key_pad ∥ message)

ฟังก์ชัน computeBlockSizedKey รับอินพุต ดังนี้: key: ไบต์ // อาร์เรย์ของไบต์ hash: ฟังก์ชัน// ฟังก์ชันแฮชที่จะใช้ (เช่น SHA-1) blockSize: จำนวนเต็ม // ขนาดบล็อกของฟังก์ชันแฮช (เช่น 64 ไบต์สำหรับ SHA-1)// คีย์ที่มีความยาวมากกว่า blockSize จะถูกย่อให้สั้นลงโดยการแฮชหาก (length(key) > blockSize) แล้ว คีย์ = แฮช(คีย์) // คีย์ที่สั้นกว่า blockSize จะถูกเติมด้วยศูนย์ทางด้านขวาจนมีความยาวเท่ากับ blockSize หาก (length(key) < blockSize) แล้วให้คืนค่า Pad(key, blockSize) // เติมคีย์ด้วยศูนย์เพื่อให้มี ความยาวเท่ากับ blockSize ไบต์ปุ่มย้อนกลับ

การออกแบบข้อกำหนด HMAC ได้รับแรงบันดาลใจจากการมีอยู่ของการโจมตีกลไกที่ง่ายกว่าสำหรับการรวมคีย์กับฟังก์ชันแฮช ตัวอย่างเช่น อาจสันนิษฐานได้ว่าความปลอดภัยแบบเดียวกันกับที่ HMAC ให้สามารถทำได้ด้วย MAC = H ( key ∥ message ) อย่างไรก็ตาม วิธีนี้มีข้อบกพร่องร้ายแรง: ด้วยฟังก์ชันแฮชส่วนใหญ่ การเพิ่มข้อมูลลงในข้อความโดยไม่ทราบคีย์และได้ MAC ที่ถูกต้องอีกตัวหนึ่งนั้นทำได้ง่าย (" การโจมตีแบบขยายความยาว ") ทางเลือกอื่น การเพิ่มคีย์โดยใช้ MAC = H ( message ∥ key ) ประสบปัญหาที่ว่าผู้โจมตีที่สามารถหาการชนกันในฟังก์ชันแฮช (ที่ไม่มีคีย์) จะพบการชนกันใน MAC ด้วย (เนื่องจากข้อความสองข้อความ m1 และ m2 ที่ให้แฮชเดียวกันจะให้เงื่อนไขเริ่มต้นเดียวกันแก่ฟังก์ชันแฮชก่อนที่จะแฮชคีย์ที่เพิ่มเข้ามา ดังนั้นแฮชสุดท้ายจึงเหมือนกัน) การใช้ MAC = H ( key ∥ message ∥ key ) จะดีกว่า แต่เอกสารด้านความปลอดภัยต่างๆ ได้ชี้ให้เห็นถึงช่องโหว่ในแนวทางนี้ แม้ว่าจะใช้คีย์ที่แตกต่างกันสองคีย์ก็ตาม^{[ 1 ] [ 7 ] [ 8 ]}

ยังไม่พบการโจมตีส่วนขยายใดๆ ที่รู้จักต่อข้อกำหนด HMAC ปัจจุบัน ซึ่งกำหนดไว้เป็นH ( key ∥ H ( key ∥ message )) เนื่องจากการประยุกต์ใช้ฟังก์ชันแฮชภายนอกจะปกปิดผลลัพธ์ระดับกลางของแฮชภายใน ค่าของipadและopadไม่ได้มีความสำคัญต่อความปลอดภัยของอัลกอริทึม แต่ถูกกำหนดไว้ในลักษณะที่ให้มีระยะห่างแฮมมิง (Hamming distance) มาก จากกันและกัน ดังนั้นคีย์ภายในและภายนอกจะมีบิตที่เหมือนกันน้อยลง การลดความปลอดภัยของ HMAC จำเป็นต้องให้คีย์ทั้งสองแตกต่างกันอย่างน้อยหนึ่งบิต

ฟังก์ชัน แฮช Keccak ซึ่ง NISTเลือกให้เป็น ผู้ชนะการแข่งขัน SHA-3ไม่จำเป็นต้องใช้วิธีการซ้อนกันแบบนี้ และสามารถใช้สร้าง MAC ได้โดยการเพิ่มคีย์ไว้ข้างหน้าข้อความเท่านั้น เนื่องจากไม่ไวต่อการโจมตีแบบขยายความยาว^{[ 9 ]}

ความแข็งแกร่งทางด้านการเข้ารหัสของ HMAC ขึ้นอยู่กับขนาดของกุญแจลับที่ใช้และความปลอดภัยของฟังก์ชันแฮชพื้นฐานที่ใช้ มีการพิสูจน์แล้วว่าความปลอดภัยของโครงสร้าง HMAC เกี่ยวข้องโดยตรงกับคุณสมบัติความปลอดภัยของฟังก์ชันแฮชที่ใช้ การโจมตีที่พบบ่อยที่สุดต่อ HMAC คือการใช้กำลังแบบ Brute Force เพื่อเปิดเผยกุญแจลับ HMAC ได้รับผลกระทบจากการชนกันน้อยกว่าอัลกอริธึมการแฮชพื้นฐานเพียงอย่างเดียว^{[ 2 ] [ 10 ] [ 11 ]} โดยเฉพาะอย่างยิ่ง Mihir Bellare ได้พิสูจน์ว่า HMAC เป็นฟังก์ชันสุ่มเทียม (PRF) ภายใต้สมมติฐานเพียงอย่างเดียวว่าฟังก์ชันการบีบอัดเป็น PRF ^{[ 12 ]}ดังนั้น HMAC-MD5 จึงไม่มีจุดอ่อนเช่นเดียวกับที่พบใน MD5 ^{[ 13 ]}

RFC 2104 กำหนดให้ "คีย์ที่มีความยาวมากกว่าBไบต์จะต้องถูกแฮชโดยใช้H ก่อน " ซึ่งนำไปสู่การชนกันเทียมที่สับสน: หากคีย์มีความยาวมากกว่าขนาดบล็อกแฮช (เช่น 64 ไบต์สำหรับ SHA-1) HMAC(k, m)จะถูกคำนวณเป็นHMAC(H(k), m)คุณสมบัตินี้บางครั้งถูกยกขึ้นมาเป็นจุดอ่อนที่เป็นไปได้ของ HMAC ในสถานการณ์การแฮชรหัสผ่าน: มีการแสดงให้เห็นแล้วว่าเป็นไปได้ที่จะพบสตริง ASCII ยาวและค่าสุ่มที่มีแฮชเป็นสตริง ASCII เช่นกัน และทั้งสองค่าจะสร้างเอาต์พุต HMAC เดียวกัน^{[ 14 ] [ 15 ] [ 16 ]}

ในปี 2549 Jongsung Kim , Alex Biryukov , Bart PreneelและSeokhie Hongได้แสดงวิธีการแยกแยะ HMAC ที่ใช้ MD5 และ SHA-1 เวอร์ชันลดรูป หรือHAVAL , MD4และSHA-0 เวอร์ชันเต็ม ออก จากฟังก์ชันสุ่มหรือ HMAC ที่ใช้ฟังก์ชันสุ่ม ตัวแยกแยะความแตกต่างช่วยให้ผู้โจมตีสามารถคิดค้นการโจมตีปลอมแปลงบน HMAC ได้ นอกจากนี้ ตัวแยกแยะความแตกต่างแบบดิฟเฟอเรนเชียลและแบบสี่เหลี่ยมผืนผ้ายังสามารถนำไปสู่การโจมตีแบบภาพก่อนหน้าลำดับที่สอง ได้อีก ด้วย HMAC ที่ใช้ MD4 เวอร์ชันเต็มสามารถปลอมแปลงได้ด้วยความรู้นี้ การโจมตีเหล่านี้ไม่ได้ขัดแย้งกับการพิสูจน์ความปลอดภัยของ HMAC แต่ให้ข้อมูลเชิงลึกเกี่ยวกับ HMAC โดยอิงจากฟังก์ชันแฮชการเข้ารหัสที่มีอยู่^{[ 17 ]}

ในปี 2552 Xiaoyun Wang และคณะได้นำเสนอการโจมตีแบบแยกแยะบน HMAC-MD5 โดยไม่ต้องใช้คีย์ที่เกี่ยวข้อง ซึ่งสามารถแยกแยะอินสแตนซ์ของ HMAC ที่มี MD5 จากอินสแตนซ์ที่มีฟังก์ชันสุ่มด้วยการสอบถาม 2 ⁹⁷ครั้งด้วยความน่าจะเป็น 0.87 ^{[ 18 ]}

ในปี 2554 มีการเผยแพร่ RFC 6151 เพื่อสรุปข้อควรพิจารณาด้านความปลอดภัยในMD5และ HMAC-MD5 สำหรับ HMAC-MD5 นั้น RFC สรุปว่า แม้ว่าความปลอดภัยของ ฟังก์ชันแฮช MD5เองจะถูกบุกรุกอย่างรุนแรง แต่"การโจมตี HMAC-MD5 ที่ทราบในปัจจุบันดูเหมือนจะไม่บ่งชี้ถึงช่องโหว่ในทางปฏิบัติเมื่อใช้เป็นรหัสยืนยันข้อความ"แต่ก็ยังเสริมว่า"สำหรับการออกแบบโปรโตคอลใหม่ ไม่ควรมีชุดการเข้ารหัสที่มี HMAC-MD5 " ^{[ 13 ]}

ในเดือนพฤษภาคม พ.ศ. 2554 RFC 6234 ได้รับการเผยแพร่โดยให้รายละเอียดเกี่ยวกับทฤษฎีเชิงนามธรรมและซอร์สโค้ดสำหรับ HMAC ที่ใช้ SHA ^{[ 19 ]}

ต่อไปนี้คือค่า HMAC บางส่วน โดยสมมติว่าใช้ ASCII 8 บิตสำหรับข้อมูลนำเข้า และการเข้ารหัสเลขฐานสิบหกสำหรับข้อมูลส่งออก:

HMAC_MD5("key", "The quick brown fox jumps over the lazy dog") = 80070713463e7749b90c2dc24911e275 HMAC_SHA1("key", "The quick brown fox jumps over the lazy dog") = de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9 HMAC_SHA256("key", "The quick brown fox jumps over the lazy dog") = f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 HMAC_SHA512("key", "The quick brown fox jumps over the lazy dog") = b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a 

• รหัสผ่านใช้ครั้งเดียวแบบ HMAC

• เครื่องมือสร้าง/ทดสอบ HMAC ออนไลน์
• FIPS PUB 198-1, รหัสยืนยันข้อความแบบแฮชที่มีคีย์ (HMAC)เก็บถาวรเมื่อวันที่ 17 กุมภาพันธ์ 2013 ที่Wayback Machine
• การใช้งาน C HMAC
• การใช้งาน HMAC ในภาษา Python
• การใช้งาน Java
• การใช้งาน HMAC ในภาษา Rust