Mã xác thực thông điệp (MAC, Message Authentication Code)

1. Tổng quan

A. Định nghĩa

MAC (Message Authentication Code) là thẻ xác thực có độ dài cố định được tạo ra từ đầu vào gồm thông điệp và khóa bí mật chỉ bên gửi và bên nhận chia sẻ, là kỹ thuật mật mã khóa đối xứng kiểm chứng đồng thời rằng thông điệp không bị sửa đổi trong quá trình truyền (tính toàn vẹn, Integrity) và được gửi bởi bên gửi hợp lệ biết khóa bí mật (xác thực nguồn gốc, Data-Origin Authentication).

Để hiểu bối cảnh ra đời của MAC, trước hết cần xuất phát từ câu hỏi "tại sao chỉ dùng hàm băm đơn thuần là chưa đủ". Cách đơn giản nhất để bảo đảm tính toàn vẹn của thông điệp là gắn giá trị băm như SHA-256 vào thông điệp khi gửi, và bên nhận tính lại giá trị băm để so sánh. Tuy nhiên, hàm băm là thuật toán công khai nên có lỗ hổng chí mạng là ai cũng có thể tính được. Kẻ tấn công xen giữa (MITM) chỉ cần giả mạo thông điệp tùy ý rồi tính lại và gắn giá trị băm mới của thông điệp giả mạo đó, bên nhận sẽ hoàn toàn không nhận ra sự sửa đổi. Tức là băm đơn thuần phát hiện được lỗi truyền thông (thay đổi ngẫu nhiên) nhưng không ngăn được tấn công ác ý (giả mạo có chủ đích).

MAC khép lại chính điểm này bằng khóa bí mật. Hàm tạo MAC có dạng MAC = f(K, M), nhận đầu vào không chỉ thông điệp M mà còn khóa bí mật K chỉ bên gửi và bên nhận biết. Kẻ tấn công không biết khóa K nên dù sửa đổi thông điệp cũng không thể tạo ra MAC đúng tương ứng. Bên nhận dùng thông điệp nhận được và cùng khóa mà mình lưu giữ để tính lại MAC, rồi kiểm tra xem có khớp với MAC đến kèm không. Nếu khớp, có thể đồng thời tin chắc hai sự thật: "① thông điệp không bị thay đổi trong quá trình truyền (tính toàn vẹn), ② chỉ đối tác hợp lệ có cùng khóa mới tạo được MAC này nên chính họ đã gửi (xác thực nguồn gốc)". Tóm lại, bản chất của MAC là 'keyed hash (băm phụ thuộc khóa) chỉ tính toán và kiểm chứng được khi có khóa', và tính chất keyed này gắn kết tính toàn vẹn với xác thực thành một.

B. Bối cảnh ra đời và sự cần thiết

Truyền thông hiện đại lấy tiền đề là các kênh không đáng tin cậy như Internet, mạng không dây. Nếu thông điệp giao dịch tài chính bị đổi giữa chừng từ "chuyển 1 triệu won" thành "10 triệu won", hoặc lệnh điều khiển do cảm biến IoT gửi bị giả mạo, thiệt hại sẽ rất lớn. Khi đó, chỉ tính bí mật (mã hóa) là chưa đủ. Bởi ngay cả bản mã cũng có thể bị sửa đổi bằng cách lật bit, và đặc biệt với mã dòng hoặc chế độ CTR có thể thực hiện tấn công lật bit (bit-flipping) thao túng có thể dự đoán các bit bản rõ cụ thể. Do đó, tách biệt với việc "che giấu nội dung", nhất thiết cần một cơ chế bảo đảm "nội dung không bị thay đổi và do đối tác hợp lệ gửi", và MAC là thứ cung cấp điều này nhanh và hiệu quả dựa trên khóa đối xứng. Trên thực tế, MAC nằm ở nền tảng của hầu hết các giao thức bảo mật ngày nay như TLS, IPSec, SSH, JWT (JSON Web Token), kiểm chứng chữ ký của OAuth.

2. Nguyên lý hoạt động và cấu trúc tổng thể

A. Sơ đồ cấu trúc tổng thể

Luồng tổng thể của truyền thông dựa trên MAC diễn ra đối xứng giữa "phía tạo (gửi)" và "phía kiểm chứng (nhận)" trong trạng thái chia sẻ cùng một khóa bí mật như sau.

flowchart LR
  subgraph SND["Bên gửi (Sender)"]
    M1["Thông điệp gốc M"] --> GEN["Hàm tạo MAC f(K, M)"]
    K1["Khóa bí mật chung K"] --> GEN
    GEN --> T1["Thẻ xác thực MAC"]
  end
  M1 --> CH["Truyền: thông điệp M + MAC"]
  T1 --> CH
  CH --> RCV
  subgraph RCV["Bên nhận (Receiver)"]
    M2["Thông điệp nhận M'"] --> GEN2["Tính lại MAC f(K, M')"]
    K2["Khóa bí mật chung K"] --> GEN2
    GEN2 --> T2["MAC' tính lại"]
    T2 --> CMP{"MAC' == MAC nhận được ?"}
    CMP -->|Khớp| OK["Toàn vẹn·xác thực thành lập → chấp nhận"]
    CMP -->|Không khớp| NG["Nghi sửa đổi·giả mạo → hủy"]
  end
  style GEN fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style CMP fill:#fff3e0,stroke:#f57c00,stroke-width:2px

Cốt lõi của cấu trúc này là tính đối xứng: bên gửi và bên nhận thực hiện hoàn toàn cùng một phép toán. Khóa bí mật K phải được phân phối trước cho hai bên qua kênh an toàn (giao thức trao đổi khóa hoặc chia sẻ trước), và ngay khi tính bí mật của khóa này bị phá vỡ, toàn bộ hệ thống MAC bị vô hiệu hóa. Tức là độ an toàn của MAC phụ thuộc quyết định không chỉ vào sức mạnh thuật toán mà còn vào hệ thống quản lý khóa.

B. Chi tiết thủ tục tạo và kiểm chứng

Thủ tục phía gửi kết thúc với ① đưa thông điệp M và khóa bí mật K vào hàm MAC để tính thẻ, ② gửi thông điệp cùng thẻ. Ở đây, bản thân thông điệp (nếu không cần tính bí mật) gửi dưới dạng bản rõ cũng không sao. Vì vai trò của MAC không phải "che giấu" mà là "niêm phong".

Nguyên lý quan trọng nhất trong thủ tục phía nhận là tính lại - so sánh (recompute and compare). Bên nhận tự tính lại MAC từ thông điệp M' nhận được. Nếu trong quá trình truyền dù chỉ 1 bit bị thay đổi, do hiệu ứng thác lũ (avalanche effect) của hàm băm, MAC được tính lại sẽ trở thành giá trị hoàn toàn khác giá trị ban đầu và phép so sánh thất bại. Khi đó có một nguyên tắc thực tiễn nhất định phải tuân thủ: việc so sánh MAC phải được thực hiện bằng so sánh thời gian hằng (constant-time comparison). So sánh chuỗi thông thường so từng byte một và trả về ngay tại điểm không khớp đầu tiên sẽ dễ bị tấn công thời gian (timing attack), trong đó kẻ tấn công dò ra MAC đúng từng byte một dựa trên chênh lệch rất nhỏ của thời gian phản hồi. Vì vậy trong thực tế dùng các hàm thời gian hằng như hmac.compare_digest (Python), crypto.timingSafeEqual (Node.js).

C. Cấu trúc bên trong của thuật toán tiêu biểu (HMAC)

HMAC, được dùng rộng rãi nhất, được thiết kế theo cấu trúc "lồng hàm băm hai lần để kết hợp khóa một cách an toàn". Cách đơn giản gắn khóa lên trước như H(K || M) sẽ bị phơi nhiễm trước tấn công mở rộng độ dài (length-extension attack) của hàm băm có cấu trúc Merkle-Damgård. Để ngăn điều này, HMAC dùng cấu trúc băm kép với phần đệm trong (ipad) và phần đệm ngoài (opad).

flowchart TB
  K["Khóa bí mật K"] --> PAD["Đệm khóa (chuẩn hóa theo kích thước khối)"]
  PAD --> XI["K ⊕ ipad"]
  PAD --> XO["K ⊕ opad"]
  M["Thông điệp M"] --> C1["Băm trong: H((K⊕ipad) || M)"]
  XI --> C1
  C1 --> C2["Băm ngoài: H((K⊕opad) || kết quả băm trong)"]
  XO --> C2
  C2 --> OUT["Giá trị HMAC (ví dụ: 256bit)"]
  style C1 fill:#e8f0fe,stroke:#2f6fed
  style C2 fill:#e8f5e9,stroke:#2e7d32
  style OUT fill:#fff3e0,stroke:#f57c00

Nhờ cấu trúc kép này, HMAC miễn nhiễm với tấn công mở rộng độ dài với tiền đề hàm băm được dùng (SHA-256, SHA-3, v.v.) là an toàn, và được tin cậy vì có chứng minh bảo mật (security proof). Trong thực tế, HMAC-SHA256 đã trở thành chuẩn trên thực tế, được dùng rộng rãi trong chữ ký HS256 của JWT, xác thực yêu cầu của AWS Signature Version 4, kiểm chứng toàn vẹn của TLS, v.v.

3. Các loại MAC

MAC được chia thành ba dòng lớn tùy theo sử dụng hàm nguyên thủy (primitive) nền tảng nào. Mỗi dòng có đặc tính hiệu năng và môi trường sử dụng khác nhau, vì vậy quan điểm quan trọng là lựa chọn theo môi trường, chứ không phải một loại luôn vượt trội.

Loại	Nền tảng	Đặc điểm và ngữ cảnh sử dụng
HMAC	Hàm băm (SHA-256/512, SHA-3)	Dùng rộng rãi nhất. Hiện thực phần mềm đơn giản, có chứng minh bảo mật. Dùng tiêu chuẩn trong JWT·TLS·chữ ký API
CMAC	Mã khối (AES)	Có lợi trong môi trường có tăng tốc phần cứng mã khối (AES-NI). Cung cấp xác thực chỉ bằng AES, không cần mô-đun băm riêng
GMAC	Phần xác thực của chế độ GCM	Dựa trên phép nhân trường hữu hạn GF(2¹²⁸). Thuận lợi cho xử lý song song nên tốc độ cao. Dùng làm thẻ xác thực của AES-GCM (AEAD)

HMAC chỉ cần hàm băm là hiện thực được nên tính khả chuyển rất tốt và được thư viện hỗ trợ rộng rãi. Ngược lại, CMAC có cấu trúc nối chuỗi mã khối theo cách tương tự CBC và lấy khối cuối làm thẻ, có thể giảm kích thước mã trong môi trường IoT/nhúng vốn đã dùng tăng tốc phần cứng AES. GMAC là phần xác thực tách ra từ GCM (Galois/Counter Mode), có thể song song hóa phép nhân trường hữu hạn nên được ưa chuộng trong thiết bị mạng tốc độ cao cỡ 10Gbps. Chẳng hạn, TLS 1.3 chỉ giữ lại các phương thức AEAD như AES-128-GCM, ChaCha20-Poly1305 và loại bỏ tổ hợp CBC+HMAC cũ, đây là lựa chọn nhằm đạt được đồng thời hiệu năng và độ an toàn.

4. So sánh với chữ ký số, hàm băm và các ví dụ

A. So sánh với chữ ký số — có hay không chống chối bỏ

MAC và chữ ký số đều cung cấp "toàn vẹn + xác thực nguồn gốc", nhưng khác biệt quyết định ở chống chối bỏ (Non-repudiation). Lý do căn bản tạo ra khác biệt này nằm ở tính đối xứng/bất đối xứng của khóa.

Phân loại	MAC	Chữ ký số (Digital Signature)
Hệ thống khóa	Khóa đối xứng (hai bên chia sẻ một khóa bí mật)	Khóa bất đối xứng (ký bằng khóa riêng, kiểm chứng bằng khóa công khai)
Thuộc tính bảo mật cung cấp	Toàn vẹn + xác thực nguồn gốc	Toàn vẹn + xác thực nguồn gốc + chống chối bỏ
Tốc độ tính toán	Rất nhanh (phép toán đối xứng)	Chậm (phép toán khóa công khai, chậm hơn hàng chục~hàng trăm lần)
Chống chối bỏ	Không thể — chia sẻ khóa nên không thể chứng minh cho bên thứ ba	Có thể — khóa riêng chỉ người ký nắm giữ
Thuật toán tiêu biểu	HMAC, CMAC, GMAC	RSA, ECDSA, EdDSA

Lý do MAC không thể chống chối bỏ rất rõ ràng. Vì bên gửi và bên nhận chia sẻ cùng một khóa bí mật, khi muốn chứng minh với bên thứ ba (thẩm phán, trọng tài) rằng "MAC này do bên gửi tạo ra", thì bên nhận cũng có thể tạo MAC đó bằng cùng khóa, nên bên gửi có thể chối bỏ "tôi không gửi, chẳng phải anh tạo ra sao". Ngược lại, chữ ký số được ký bằng khóa riêng chỉ người ký có và ai cũng kiểm chứng được bằng khóa công khai, nên chống chối bỏ thành lập theo lập luận "chỉ chủ sở hữu khóa riêng mới tạo được chữ ký này". Do đó, nguyên tắc thực tiễn là dùng chữ ký số ở những nơi cần chống chối bỏ như giá trị chứng cứ pháp lý, hợp đồng, văn bản điện tử, và dùng MAC cho kiểm chứng toàn vẹn nhanh trong phiên.

B. So sánh với băm đơn thuần

Băm đơn thuần (chỉ SHA-256) không có khóa nên chỉ hiệu quả cho phát hiện lỗi ngẫu nhiên. So sánh checksum khi tải tệp là một ví dụ. Tuy nhiên, như đã giải thích, nếu kẻ tấn công tính lại cả giá trị băm thì nó vô dụng, vì vậy với truyền thông có giả định giả mạo ác ý nhất thiết cần MAC là phương thức keyed. Có thể tóm tắt: "checksum ngăn sai sót, MAC ngăn tấn công".

C. Ví dụ áp dụng cụ thể

Thứ nhất, HS256 của JWT (JSON Web Token) gắn thẻ ký header và payload bằng HMAC-SHA256 để kiểm chứng token do máy chủ cấp không bị giả mạo ở phía client. Tuy nhiên ở đây có một lỗ hổng nổi tiếng, đó là tấn công nhầm lẫn thuật toán (algorithm confusion): đổi thuật toán ký thành none hoặc dụ máy chủ dùng nhầm khóa công khai RSA của máy chủ làm khóa HMAC. Đây không phải khiếm khuyết của bản thân MAC mà là vấn đề hiện thực logic kiểm chứng, là ví dụ tiêu biểu cho thấy máy chủ phải cố định tường minh thuật toán được phép.

Thứ hai, AWS Signature Version 4 ký nối chuỗi từng thành phần của yêu cầu API (phương thức HTTP, URI, header, dấu thời gian) bằng HMAC-SHA256, để kiểm chứng yêu cầu không bị sửa đổi khi truyền và do chủ sở hữu thông tin xác thực hợp lệ gửi. Nhờ đưa dấu thời gian vào, nó còn phòng được tấn công phát lại (replay attack).

Thứ ba, trong thẻ IC tài chính và thanh toán EMV, dòng CMAC được dùng để bảo đảm tính toàn vẹn của thông điệp giao dịch giữa thiết bị đầu cuối và thẻ. Vì đặc thù môi trường nhúng, CMAC tái sử dụng phần cứng AES nên tiết kiệm tài nguyên.

5. Chuyên sâu — Tiến hóa sang AEAD và xu hướng tiêu chuẩn mới nhất

Ngày nay, MAC thay vì dùng riêng lẻ đã phát triển thành dạng mã hóa có xác thực kết hợp với mã hóa (AEAD, Authenticated Encryption with Associated Data). Trước đây nhà phát triển phải tự chọn thứ tự kết hợp như "mã hóa rồi MAC (Encrypt-then-MAC)", "MAC rồi mã hóa (MAC-then-Encrypt)", và nếu kết hợp sai sẽ lộ ra các lỗ hổng nghiêm trọng như tấn công padding oracle (Padding Oracle), Lucky 13. Thực tế, khi các tấn công này liên tiếp được báo cáo trên tổ hợp CBC+HMAC của TLS, một phương thức tích hợp loại bỏ khả năng sai thứ tự đã trở nên cần thiết.

Kết quả đó là AEAD. AES-GCM gộp mã hóa và tạo thẻ xác thực GMAC thành một phép toán, cung cấp đồng thời tính bí mật, toàn vẹn và xác thực. Ngoài ra, nó có thể đưa vào thẻ cả dữ liệu phụ (Associated Data) kiểu "không mã hóa nhưng phải bảo đảm toàn vẹn" như header. Trong môi trường di động và tiết kiệm năng lượng, ChaCha20-Poly1305 nhanh ngay cả khi không có tăng tốc phần cứng AES-NI được ưa chuộng, trong đó Poly1305 đóng vai trò MAC. TLS 1.3 (RFC 8446) chỉ giữ lại các phương thức AEAD này làm chuẩn và loại bỏ hoàn toàn các tổ hợp cũ như CBC+HMAC.

Mặt khác, trong thảo luận chuyển đổi sang mật mã kháng lượng tử (PQC) để chuẩn bị cho kỷ nguyên máy tính lượng tử, vị thế của MAC vẫn ổn định. Thứ mà thuật toán Shor đe dọa là các hệ thống khóa công khai (bất đối xứng) như RSA, ECC, còn MAC dựa trên khóa đối xứng chỉ chịu ảnh hưởng ở mức độ mạnh bảo mật hiệu dụng giảm một nửa bởi thuật toán Grover. Tức là tăng gấp đôi độ dài khóa và thẻ (ví dụ: HMAC-SHA512) là có thể duy trì đủ độ an toàn ngay cả trong kỷ nguyên lượng tử, và việc không cần thay thế căn bản như thuật toán khóa công khai đang được đánh giá lại như một thế mạnh của MAC.

6. Các điểm cần cân nhắc và hàm ý (góc độ Kỹ sư chuyên nghiệp)

Chuyển sang chữ ký số khi yêu cầu chống chối bỏ — MAC hiệu quả cho toàn vẹn và xác thực nhưng do cấu trúc đối xứng chia sẻ khóa nên về căn bản không thể chống chối bỏ. Ở những lĩnh vực cần hợp đồng điện tử, dấu vết kiểm toán, chứng cứ pháp lý, nhất định phải áp dụng chữ ký số bất đối xứng (ECDSA, EdDSA), và chiến lược kết hợp phân tầng chỉ dùng MAC cho kiểm chứng bên trong phiên nơi hiệu năng quan trọng là hợp lý.
Quản lý khóa (Key Management) là điểm yếu chí mạng của bảo mật — Độ an toàn của MAC phụ thuộc hoàn toàn vào tính bí mật của khóa chứ không phải thuật toán. Phân phối khóa phải thực hiện qua trao đổi khóa an toàn (ví dụ: ECDH) hoặc KMS/HSM, và phải có cơ chế thay khóa định kỳ (rotation), tách khóa theo mục đích, hủy ngay khi bị lộ. Tái sử dụng một khóa trong thời gian dài và cho nhiều mục đích là sai lầm thực tiễn phổ biến nhất nhưng cũng chí mạng nhất.
Phòng thủ lỗ hổng hiện thực — so sánh thời gian hằng và cố định thuật toán — Dù thuật toán MAC an toàn, nếu mã kiểm chứng lỏng lẻo thì vẫn bị vô hiệu hóa. Cần phản ánh ngay từ giai đoạn thiết kế phòng thủ ở mức hiện thực như so sánh thời gian hằng chống tấn công thời gian, cố định tường minh thuật toán được phép để chống nhầm lẫn thuật toán của JWT, đưa dấu thời gian và nonce vào để chống phát lại.
Ưu tiên áp dụng AEAD và loại trừ sai lầm về thứ tự — Khi cần cả tính bí mật, nhà phát triển không nên tự kết hợp thứ tự mã hóa và MAC mà phải áp dụng AEAD đã được kiểm chứng (AES-GCM, ChaCha20-Poly1305) làm chuẩn. Đây là lựa chọn an toàn nhất, loại bỏ về mặt cấu trúc các lỗ hổng do sai lầm kết hợp như padding oracle, Lucky 13.
Cân bằng từ góc độ chuẩn bị cho kỷ nguyên lượng tử — MAC khóa đối xứng chịu ảnh hưởng hạn chế từ thuật toán Grover nên chỉ cần mở rộng độ dài khóa và thẻ (HMAC-SHA512, v.v.) là đối phó được. Khi xây dựng lộ trình chuyển đổi PQC, chiến lược phân biệt ưu tiên tập trung nguồn lực vào các hệ thống khóa công khai (chữ ký, trao đổi khóa) và đối phó với MAC bằng cách nâng tham số là hợp lý.

Tài liệu tham khảo

RFC 2104, HMAC: Keyed-Hashing for Message Authentication — https://datatracker.ietf.org/doc/html/rfc2104
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 — https://datatracker.ietf.org/doc/html/rfc8446
NIST SP 800-38B, Recommendation for Block Cipher Modes: CMAC — https://csrc.nist.gov/pubs/sp/800/38/b/final
NIST SP 800-38D, Recommendation for GCM and GMAC — https://csrc.nist.gov/pubs/sp/800/38/d/final

Tóm tắt một câu: MAC là kỹ thuật khóa đối xứng tạo thẻ xác thực keyed từ thông điệp và khóa bí mật chung rồi tính lại để so sánh, kiểm chứng đồng thời tính toàn vẹn và xác thực nguồn gốc; có các dòng HMAC, CMAC, GMAC, và do đặc tính chia sẻ khóa nên giao việc chống chối bỏ cho chữ ký số; ngày nay nó được tích hợp với mã hóa dưới dạng AEAD như AES-GCM, và phòng thủ ở mức hiện thực như quản lý khóa và so sánh thời gian hằng là yếu tố then chốt cho độ an toàn.