Mã hoá dữ liệu là gì?

Mục lục

1. Mã hoá dữ liệu là gì?
2. Mã hoá hoạt động thế nào?
3. Các loại mã hoá: đối xứng, bất đối xứng và băm
4. Nonce là gì? (What is a nonce in security)
5. Salt là gì và vì sao mật khẩu cần salt?
6. Lưu mật khẩu: chọn thuật toán và tham số nào?
7. Ví dụ thực tế cho doanh nghiệp Việt Nam
8. Ưu điểm và hạn chế
9. Mã hoá và các khái niệm dễ nhầm
10. Khi nào nên và không nên dựa vào mã hoá?
11. Câu hỏi thường gặp

Mã hoá dữ liệu là gì?

Theo khoản 16 Điều 3 Luật Dữ liệu 2024, mã hoá dữ liệu là việc áp dụng các phương pháp, thuật toán mã hoá hoặc giải pháp kỹ thuật để chuyển dữ liệu từ định dạng nhận biết được sang định dạng không nhận biết được. Hiểu thực tế: có ba thành phần.

• Bản rõ (plaintext): dữ liệu gốc, ví dụ một file bảng lương hoặc số thẻ.
• Thuật toán (cipher): quy trình biến đổi được công bố công khai, ví dụ AES. Độ an toàn không dựa vào việc giấu thuật toán.
• Khoá (key): chuỗi bit bí mật điều khiển phép biến đổi. Mất khoá hoặc lộ khoá thì mã hoá mất tác dụng.

Kết quả là bản mã (ciphertext). Mã hoá chủ yếu bảo vệ tính bí mật, một trong ba trụ của bộ ba CIA mà bài nền tảng an toàn thông tin đã trình bày. Mã hoá không ngăn người khác lấy được file. Nó chỉ làm cho file lấy được trở nên vô nghĩa nếu không có khoá.

Mã hoá hoạt động thế nào?

Một phép mã hoá nhận hai đầu vào là bản rõ và khoá, rồi trả về bản mã. Giải mã làm ngược lại với khoá tương ứng. Với mã hoá đối xứng hiện đại như AES, dữ liệu được chia thành khối 128 bit, và khoá có thể dài 128, 192 hoặc 256 bit.

Hai trạng thái cần bảo vệ khác nhau. Dữ liệu đang lưu (at rest) thường được mã hoá bằng BitLocker, mã hoá trong suốt của cơ sở dữ liệu hoặc mã hoá phía dịch vụ lưu trữ. Dữ liệu đang truyền (in transit) được mã hoá bằng TLS trên HTTPS hoặc bằng đường hầm của mạng riêng ảo.

Các loại mã hoá: đối xứng, bất đối xứng và băm

Mã hoá đối xứng

Một khoá dùng cho cả mã hoá và giải mã. Tốc độ cao nên dùng cho khối lượng dữ liệu lớn như ổ đĩa, cơ sở dữ liệu, bản sao lưu. Điểm khó là phân phối khoá an toàn đến người nhận.

Mã hoá bất đối xứng

Mỗi bên có cặp khoá: khoá công khai để mã hoá (hoặc kiểm tra chữ ký), khoá riêng để giải mã (hoặc ký). Chậm hơn đối xứng nhiều nên thường chỉ bảo vệ một khoá phiên nhỏ, sau đó dữ liệu thật được mã hoá đối xứng. TLS hoạt động theo mô hình lai này. Cùng cặp khoá còn là nền của chữ ký số, nhưng khi ký thì khoá riêng được dùng theo chiều ngược lại.

Băm: không phải mã hoá

Hàm băm (hash) biến dữ liệu bất kỳ thành chuỗi độ dài cố định và không có khoá để giải ngược. Dùng để kiểm tra toàn vẹn file và lưu mật khẩu. Hệ thống lưu mật khẩu bằng mã hoá hai chiều là sai thiết kế: ai lấy được khoá thì lấy được toàn bộ mật khẩu gốc.

Tiêu chí	Mã hoá đối xứng	Mã hoá bất đối xứng	Băm
Số khoá	1 khoá chung	Cặp khoá công khai và riêng	Không có khoá (trừ HMAC)
Đảo ngược được	Có, khi có khoá	Có, khi có khoá riêng	Không
Tốc độ	Nhanh	Chậm hơn nhiều	Nhanh; riêng băm mật khẩu cố ý làm chậm
Dùng điển hình	Ổ đĩa, cơ sở dữ liệu, bản sao lưu	Trao đổi khoá, chữ ký số, chứng thư TLS	Kiểm tra toàn vẹn, lưu mật khẩu
Giá trị phụ trợ	Nonce hoặc IV	Số ngẫu nhiên khi ký hoặc trao khoá	Salt (khi băm mật khẩu)

Nonce là gì? (What is a nonce in security)

Nonce là viết tắt của “number used once”: một giá trị chỉ được dùng một lần trong một ngữ cảnh nhất định. Ý nghĩa cụ thể thay đổi theo nơi dùng, nên cần phân biệt.

Nonce trong mã hoá xác thực (AES-GCM)

Đây là nghĩa phổ biến nhất. Với chế độ AES-GCM, mỗi lần mã hoá bằng cùng một khoá cần một nonce riêng, độ dài thường dùng là 96 bit (12 byte). Theo mô tả trong tài liệu của NIST, SP 800-38D gọi giá trị này là IV (initialization vector), còn RFC 5116 gọi là nonce, cùng một khái niệm. Nonce không cần bí mật và thường được lưu hoặc gửi kèm bản mã. Điều bắt buộc là nó không lặp lại với cùng khoá.

Hậu quả của việc lặp lại rất nặng. Các nghiên cứu mật mã mô tả dạng tấn công “forbidden attack” của Joux: khi một cặp khoá và nonce mã hoá hai bản rõ khác nhau, kẻ tấn công có thể tính ra khoá xác thực của GCM, từ đó giả mạo dữ liệu, và còn thu được thông tin về quan hệ giữa hai bản rõ. Mã hoá vẫn “chạy bình thường” nên lỗi này không báo gì ra ngoài.

Nonce trong các ngữ cảnh khác

• Chống phát lại (replay): máy chủ gửi một nonce, máy khách đưa nó vào chữ ký hoặc phản hồi. Kẻ chặn bắt gói tin cũ không dùng lại được vì nonce đã bị tiêu thụ.
• Nonce trong CSP của web: một giá trị ngẫu nhiên mới cho mỗi lần tải trang, cho phép đúng các thẻ script mang nonce đó chạy. Đây là một lớp giảm thiểu rủi ro XSS.
• Nonce trong khai thác khối: là số được thử liên tục để băm khối thoả điều kiện độ khó. Cùng tên nhưng mục đích khác hẳn, không liên quan đến bảo mật dữ liệu.

Salt là gì và vì sao mật khẩu cần salt?

Salt là chuỗi ngẫu nhiên duy nhất cho từng mật khẩu, được ghép vào mật khẩu trước khi băm. Theo OWASP Password Storage Cheat Sheet, mục đích là chặn bảng tra dựng sẵn như rainbow table, và buộc kẻ tấn công phải dò từng hash một thay vì tính một lần rồi so với mọi hash đang lưu.

Ví dụ minh hoạ: hai nhân viên cùng đặt mật khẩu giống nhau. Nếu không có salt, hai bản ghi trong bảng users có hash giống hệt, và lộ ra ngay hai người trùng mật khẩu. Có salt riêng thì hai hash khác nhau hoàn toàn, và kẻ tấn công phải dò hai lần.

Salt không phải bí mật

Salt được lưu ngay cạnh hash vì máy chủ cần nó để kiểm tra lúc đăng nhập. Giá trị của salt là tính duy nhất, không phải tính bí mật. Các hướng dẫn thực hành thường nêu salt tối thiểu 16 byte, sinh từ bộ sinh số ngẫu nhiên an toàn mật mã, tuyệt đối không dùng một salt chung cho cả hệ thống. Lỗi hay gặp là dùng thời gian hiện tại hoặc hàm random thông thường để làm salt vì chúng đoán được.

Salt khác nonce thế nào?

Tiêu chí	Salt	Nonce / IV
Dùng với	Hàm băm mật khẩu, hàm dẫn xuất khoá	Mã hoá (AES-GCM, ChaCha20-Poly1305), giao thức xác thực
Mục đích	Làm mỗi hash khác nhau, chặn bảng tra dựng sẵn	Làm mỗi lần mã hoá khác nhau, giữ cơ chế an toàn
Cần bí mật	Không	Không
Cần duy nhất	Có, cho từng mật khẩu	Có, cho từng lần mã hoá với cùng một khoá
Nếu lặp lại	Dễ lộ mật khẩu trùng, dò hàng loạt nhanh hơn	Với AES-GCM có thể lộ khoá xác thực và quan hệ giữa các bản rõ

Cả hai cùng một triết lý: giá trị công khai nhưng phải duy nhất. Khác ở hậu quả khi lặp. Cũng có một giá trị thứ ba là pepper, một bí mật dùng chung cho cả hệ thống và cất ngoài cơ sở dữ liệu (ví dụ trong HSM hoặc kho khoá). Pepper là lớp bổ sung, không thay thế salt.

Lưu mật khẩu: chọn thuật toán và tham số nào?

Hàm băm thông dụng như SHA-256 được thiết kế để nhanh, mà nhanh thì có lợi cho kẻ dò mật khẩu bằng GPU. Vì vậy mật khẩu cần hàm băm chậm có chủ đích. Theo OWASP Password Storage Cheat Sheet, thứ tự ưu tiên như sau:

• Argon2id: cấu hình tối thiểu là bộ nhớ 19 MiB, 2 vòng lặp, song song hoá 1. Argon2 thắng cuộc thi Password Hashing Competition năm 2015 và được chuẩn hoá trong RFC 9106 (tháng 9/2021).
• scrypt: khi không có Argon2id, dùng tham số chi phí tối thiểu 2^17, kích thước khối 8, song song hoá 1.
• bcrypt: cho hệ thống cũ, hệ số công việc từ 10 trở lên, và chú ý giới hạn mật khẩu 72 byte.
• PBKDF2: lựa chọn khi cần tuân thủ FIPS. Số vòng lặp phải lớn và tăng theo thời gian.

OWASP lưu ý các thư viện hiện đại thường tự sinh và quản lý salt, nên lập trình viên không nên tự viết phần này. Các thư viện cũng đóng gói thuật toán, tham số, salt và hash vào một chuỗi duy nhất, nên khi nâng tham số sau này bạn vẫn xác minh được các hash cũ. Nguồn khuyến nghị đã được cập nhật qua nhiều phiên bản, nên hãy đối chiếu bản OWASP mới nhất trước khi chốt tham số.

Với tài khoản quản trị, băm tốt chỉ là lớp thứ hai. Lớp thứ nhất là không để mật khẩu đứng một mình, nên hãy xem thêm xác thực đa yếu tố.

Ví dụ thực tế cho doanh nghiệp Việt Nam

Các tình huống dưới đây là ví dụ minh hoạ để thấy mã hoá nằm ở đâu.

• Laptop nhân viên kinh doanh: mất máy mà ổ đĩa đã bật BitLocker thì người nhặt được không đọc được danh sách khách hàng. Khoá khôi phục cần được giữ tập trung chứ không để trong chính máy đó.
• Website bán hàng: HTTPS bảo vệ thông tin trên đường truyền. Cơ sở dữ liệu lưu mật khẩu khách bằng Argon2id kèm salt riêng. Số thẻ thanh toán thường không lưu mà giao cho cổng thanh toán, nên không phải lo khoá cho dữ liệu đó.
• Bản sao lưu: bản sao lưu lên dịch vụ ngoài công ty nên được mã hoá bằng khoá do doanh nghiệp quản lý. Khi gặp mã độc tống tiền, bản sao lưu mã hoá và tách biệt là điều kiện để khôi phục, xem thêm bài về mã độc tống tiền.
• Trường dữ liệu nhạy cảm trong ứng dụng: với số CCCD, số điện thoại hoặc dữ liệu sức khoẻ, mã hoá ở cấp trường (field-level) cho phép chỉ bộ phận được phân quyền mới giải mã được, kể cả khi quản trị viên cơ sở dữ liệu xem được bảng. Việc này là một biện pháp kỹ thuật phục vụ nghĩa vụ bảo vệ dữ liệu cá nhân.

Ưu điểm và hạn chế

Ưu điểm

• Làm giảm thiệt hại khi thiết bị hoặc bản sao lưu bị mất, vì dữ liệu lấy được vẫn không đọc được.
• Có thuật toán chuẩn, đã được thẩm định công khai nhiều năm, và thư viện tích hợp sẵn trong hầu hết hệ điều hành và cơ sở dữ liệu.
• Mã hoá xác thực như AES-GCM còn phát hiện được dữ liệu bị sửa.

Hạn chế

• Không chống được kẻ đã có tài khoản hợp lệ: khi phần mềm đang chạy và đã giải mã, người dùng bị chiếm tài khoản vẫn đọc được. Mã hoá không thay được phân quyền.
• Quản lý khoá là phần khó: sinh, lưu, xoay vòng, thu hồi, sao lưu khoá. Mất khoá nghĩa là mất dữ liệu vĩnh viễn.
• Lỗi triển khai như dùng lại nonce, dùng chế độ ECB, hoặc tự chế thuật toán thường nguy hiểm hơn việc chọn AES-128 hay AES-256.
• Tốn thêm tài nguyên và làm phức tạp việc tìm kiếm hoặc sắp xếp trên cột đã mã hoá.

Mã hoá và các khái niệm dễ nhầm

• Mã hoá và băm: mã hoá đảo ngược được nhờ khoá, băm thì không. Cần khôi phục dữ liệu gốc thì mã hoá, chỉ cần kiểm tra khớp thì băm.
• Mã hoá và mã hoá Base64: Base64 chỉ là cách biểu diễn dữ liệu nhị phân thành ký tự, không có khoá và ai cũng giải ngược được. Dữ liệu chỉ “Base64” không được tính là đã mã hoá.
• Mã hoá và chữ ký số: chữ ký đảm bảo xuất xứ và toàn vẹn, không nhằm giấu nội dung. Chi tiết nằm trong bài về chữ ký số.
• Mã hoá và ẩn danh hoá: mã hoá có thể giải ngược bằng khoá, nên dữ liệu đã mã hoá vẫn được coi là có thể liên kết lại với cá nhân.

Khi nào nên và không nên dựa vào mã hoá?

Nên dùng ở các điểm dữ liệu rời khỏi vùng kiểm soát: laptop, USB, bản sao lưu ngoài, truyền qua Internet, lưu trên dịch vụ của bên thứ ba, và ở các trường nhạy cảm cần chia quyền theo vai trò.

Không nên coi là đủ trong những trường hợp sau: khoá nằm cùng ổ với dữ liệu, mật khẩu bảo vệ khoá quá yếu, ứng dụng giải mã tự động cho mọi người dùng đăng nhập, hoặc nhóm chưa có người nắm quy trình khôi phục khoá. Khi đó dữ liệu “đã mã hoá” nhưng thực chất ai cũng đọc được qua đường ứng dụng.

Một câu hỏi kiểm tra nhanh: nếu kẻ xấu lấy được toàn bộ ổ đĩa và bản sao cơ sở dữ liệu nhưng không có khoá, họ đọc được gì? Nếu câu trả lời là “không gì” và khoá được cất ở nơi khác thì mã hoá đang làm đúng việc.

Câu hỏi thường gặp

Mã hoá dữ liệu có làm dữ liệu an toàn tuyệt đối không?

Không. Mã hoá bảo vệ tính bí mật của dữ liệu khi không có khoá. Nó không chặn việc dữ liệu bị lấy cắp, không chống kẻ đã chiếm tài khoản hợp lệ, và không bảo vệ nếu khoá bị lộ hoặc triển khai sai.

Salt có cần giữ bí mật không?

Không. Salt thường nằm cùng hash trong cơ sở dữ liệu. Điều cần là nó ngẫu nhiên, đủ dài (thường từ 16 byte) và riêng cho từng mật khẩu. Bí mật cho cả hệ thống là vai trò của pepper.

Nonce là gì và khác gì IV?

Nonce là giá trị chỉ dùng một lần cho mỗi lần mã hoá với cùng một khoá. Trong AES-GCM, tài liệu NIST gọi nó là IV còn RFC 5116 gọi là nonce, nên hai tên chỉ cùng một thứ. Với một số chế độ khác như CBC, IV còn phải khó đoán chứ không chỉ cần duy nhất.

Có nên mã hoá mật khẩu người dùng thay vì băm không?

Không. Mật khẩu chỉ cần được so khớp, không cần đọc lại bản gốc. Băm chậm kèm salt, ví dụ Argon2id theo khuyến nghị của OWASP, cho phép kiểm tra đăng nhập mà không để lại khoá nào có thể làm lộ toàn bộ mật khẩu.

AES-128 và AES-256 khác nhau ở đâu, nên chọn loại nào?

Khác ở độ dài khoá (128 và 256 bit). Cả hai đều được NIST chấp thuận. Với phần lớn doanh nghiệp, việc quản lý khoá và tạo nonce đúng cách quan trọng hơn chênh lệch giữa hai loại. Tiêu chuẩn của ngành hoặc yêu cầu hợp đồng có thể quy định rõ mức tối thiểu, bạn nên kiểm tra các yêu cầu này trước.

Mã hoá có bắt buộc theo luật Việt Nam không?

Luật Dữ liệu 2024 có định nghĩa mã hoá dữ liệu, và các quy định về bảo mật dữ liệu, an toàn thông tin nêu mã hoá như một biện pháp kỹ thuật. Mức bắt buộc cụ thể phụ thuộc loại dữ liệu, ngành và cấp độ hệ thống. Bạn nên đối chiếu văn bản áp dụng cho lĩnh vực của mình hoặc hỏi tư vấn pháp lý chuyên môn.