Học mật mã và PKI qua mã hóa, hash, chữ ký số và chứng thư; thực hành OpenSSL để phát hiện dữ liệu bị sửa, kiểm tra khóa công khai và tạo CSR trong lab riêng.
Một nhân viên nhận tệp phê duyệt và một khóa công khai trong cùng email lạ. Phần mềm báo chữ ký hợp lệ. Điều đó có đủ để chuyển tiền? Chưa: chữ ký có thể khớp khóa của chính người gửi email giả. Bài này giải thích vì sao bảo vệ dữ liệu luôn cần cả cơ chế mật mã lẫn cách thiết lập lòng tin.
Sau bài học, bạn phân biệt mã hóa, băm, chữ ký và thỏa thuận khóa; đọc vai trò của CA, chứng thư X.509 và CSR; kiểm tra chữ ký với dữ liệu giả lập. Cần biết tệp, đường dẫn, terminal và mã thoát của lệnh. Nên học trước ba mục về mục tiêu, rủi ro và đạo đức bảo mật.
Bài độc lập tham chiếu mục 022.1, giáo trình Security Essentials 1.0 tiếng Việt ngày 15/04/2026, trang in 44–70. LPI công bố phạm vi mục tiêu tại đây. Phần thực hành cập nhật ngày 23/10/2026, dùng Ubuntu 26.04.1 ARM64, OpenSSL 3.5.5 trong container cô lập. Chúng tôi chưa kiểm thử cấp chứng thư CA hoặc kết nối TLS trong bài này.
Encoding, chẳng hạn Base64, đổi biểu diễn để dữ liệu đi qua định dạng thích hợp; người biết quy tắc có thể chuyển ngược mà không có bí mật. Encryption dùng khóa để bảo vệ khả năng đọc. Hash tạo giá trị tóm lược nhằm so sánh dữ liệu; không có thao tác giải mã hash để khôi phục tệp.
Hash có không gian đầu ra hữu hạn nên không bảo đảm mọi đầu vào có kết quả khác nhau. Với hàm phù hợp, mục tiêu là khiến việc tìm va chạm hoặc tạo dữ liệu thay thế thỏa điều kiện trở nên khó về tính toán. RFC 6151 loại MD5 khỏi các ứng dụng cần chống va chạm, như chữ ký số.
Một checksum tải từ cùng nguồn bị thay thế với tệp chỉ xác nhận hai thứ đang khớp nhau. MAC bổ sung khóa bí mật dùng chung để kiểm tra toàn vẹn và tính xác thực giữa những bên biết khóa; một bên biết khóa cũng tạo được MAC. Chữ ký số dùng khóa riêng để ký, khóa công khai tương ứng để xác minh, phục vụ một mô hình tin cậy khác.
Mật khẩu lại có đặc điểm riêng: nhiều giá trị dễ đoán. Băm SHA-256 một lần không biến mật khẩu yếu thành bí mật khó dò. NIST SP 800-63B-4 yêu cầu cơ chế băm mật khẩu phù hợp với salt và cost factor trong phạm vi hướng dẫn của họ. Đây là chuẩn tham chiếu, không tự trở thành nghĩa vụ pháp lý của mọi tổ chức.
Mã hóa đối xứng dùng bí mật chung, thích hợp xử lý nhiều dữ liệu. AES là thuật toán khối; tên AES một mình chưa mô tả đủ một hệ thống an toàn. Còn cần chế độ sử dụng, nonce hoặc IV phù hợp, xác thực dữ liệu và quản lý khóa. AEAD như AES-GCM kết hợp bảo vệ bí mật với kiểm tra tính xác thực, nhưng vẫn cần tuân thủ điều kiện của cơ chế.
Mật mã bất đối xứng sử dụng cặp khóa có quan hệ toán học, nhưng không phải mọi thuật toán đều mã hóa và giải mã. RSA có các cơ chế mã hóa hoặc chữ ký với quy tắc riêng. ECDH phục vụ thỏa thuận bí mật chung. Ed25519 dùng ký và xác minh. Không đổi vai trò các thuật toán chỉ vì chúng đều có public key.
Mật mã lai kết hợp cơ chế thiết lập khóa với mã hóa đối xứng cho dữ liệu. Ví dụ TLS 1.3 xác thực bằng chứng thư có thể dùng trao đổi khóa tạm thời (EC)DHE, chữ ký và dẫn xuất khóa. Không khái quát mọi HTTPS thành việc gửi khóa AES đã mã hóa bằng RSA. RFC 8446 mô tả các chế độ thiết lập khóa và bảo vệ bản ghi.
Forward secrecy giúp hạn chế hậu quả đối với phiên cũ khi khóa dài hạn bị lộ sau đó, với điều kiện cơ chế trao đổi khóa và xử lý khóa phiên phù hợp. Nhãn TLS 1.3 chưa đủ: chế độ PSK-only không có thuộc tính này, còn dữ liệu 0-RTT có bảo đảm yếu hơn. Mã độc đọc dữ liệu ngay tại đầu cuối vẫn nằm ngoài lời hứa đó.
Mã hóa truyền tải bảo vệ một chặng kết nối; server kết thúc TLS có thể đọc nội dung để xử lý. E2EE đặt ranh giới giải mã ở các đầu cuối của ứng dụng. Cần hỏi ai giữ khóa, bản sao lưu được bảo vệ thế nào và thiết bị có an toàn không, thay vì suy ra tên tính năng bảo đảm mọi rủi ro đã hết.
Xác minh thành công cho thấy chữ ký phù hợp dữ liệu và public key theo cơ chế đã dùng. Nó không tự chứng minh người cầm khóa là trưởng phòng, dữ liệu đúng nghiệp vụ hay hành động có đủ thẩm quyền. Quy trình cấp, bảo vệ, thu hồi khóa và bằng chứng liên quan quyết định mức tin cậy tiếp theo.
Không mô tả mọi chữ ký là “mã hóa hash bằng khóa riêng”. Đó không phải định nghĩa chung áp dụng cho các thuật toán như Ed25519. Cũng không coi kết quả một lệnh là phán quyết pháp lý về chống chối bỏ. Trong tình huống mở bài, cần xác nhận khóa qua kênh đã được tổ chức tin cậy trước khi dựa vào chữ ký để xử lý yêu cầu.
PKI gồm vai trò, quy trình, chứng thư và quản lý vòng đời. Một mô hình thường gặp có root CA, CA trung gian và chứng thư dịch vụ. Client kiểm tra đường dẫn tới trust anchor mà nó tin theo chính sách. Tự ký chỉ nói về cách tạo chữ ký; nó không khiến root được mọi hệ thống chấp nhận. RFC 5280, mục 6 giải thích kiểm tra đường dẫn và đầu vào tin cậy.
Khi đọc X.509, xác định subject, issuer, khóa công khai, thời hạn, mục đích sử dụng và extensions. Với danh tính dịch vụ TLS, cần kiểm tra tên dự kiến với SAN thích hợp; đừng chỉ nhìn CN. RFC 9525 phân biệt DNS-ID và IP-ID. Chuỗi ký hợp lệ nhưng tên dịch vụ không phù hợp vẫn là vấn đề cần xử lý.
DV xác minh kiểm soát tên miền; OV và EV có yêu cầu xác minh thông tin tổ chức khác theo chính sách cấp. Không loại nào bảo đảm nội dung trang trung thực hoặc mọi giao dịch an toàn. Let’s Encrypt mô tả ACME theo bước chứng minh kiểm soát tên miền rồi yêu cầu cấp hoặc thu hồi chứng thư.
CSR chứa khóa công khai, thông tin yêu cầu và chữ ký tương ứng; khóa riêng được giữ lại. CA còn phải kiểm tra và quyết định yêu cầu. Theo dõi gia hạn, hạn dùng và xử lý khi khóa lộ; đừng mặc định mọi client kiểm tra thu hồi giống nhau. Thêm root vào kho tin cậy có thể mở rộng những chứng thư client chấp nhận, nên phải theo quy trình quản trị.
Dùng terminal trong môi trường thực hành riêng, không chạy với khóa thật. Lab đã chạy nonroot, không mạng ngoài, filesystem gốc chỉ đọc và thư mục tạm dùng một lần. Các khóa dưới đây không có mật khẩu bảo vệ vì chỉ tồn tại trong fixture cô lập rồi bị hủy; đây không phải cách lưu khóa production.
umask 077
work=$(mktemp -d)
cd "$work"
printf '%s\n' 'LAB-DEMO ticket=28 action=approve amount=120' > message.txt
openssl genpkey -algorithm ED25519 -out sign.key
openssl pkey -in sign.key -pubout -out sign.pub
openssl pkeyutl -sign -rawin -inkey sign.key \
-in message.txt -out message.sig
openssl pkeyutl -verify -rawin -pubin -inkey sign.pub \
-sigfile message.sig -in message.txt
Kỳ vọng Signature Verified Successfully, mã thoát 0. umask 077 hạn chế quyền tệp mới; sign.key là bí mật, không đính kèm khi gửi chữ ký. Tài liệu pkeyutl 3.5 nêu Ed25519 ký/xác minh theo cách đọc toàn bộ dữ liệu. Dùng tệp nhỏ, không thay đầu vào bằng pipe hoặc tự băm trước rồi gọi đó là cùng phép thử.
printf '%s\n' 'LAB-DEMO ticket=28 action=approve amount=900' > changed.txt
openssl pkeyutl -verify -rawin -pubin -inkey sign.pub \
-sigfile message.sig -in changed.txt
openssl genpkey -algorithm ED25519 -out other.key
openssl pkey -in other.key -pubout -out other.pub
openssl pkeyutl -verify -rawin -pubin -inkey other.pub \
-sigfile message.sig -in message.txt
Hai lần xác minh phải có mã thoát khác 0. Lần đầu đổi dữ liệu, lần sau đổi khóa, trong khi giữ chữ ký cũ. Nếu chạy script có set -e, đặt phép thử âm trong if để lỗi mong đợi không làm dừng kiểm tra còn lại. Không kết luận có người tấn công từ lỗi chữ ký: sai tệp, xuống dòng khác hoặc sai khóa cũng có thể gây lỗi.
openssl genpkey -algorithm EC \
-pkeyopt ec_paramgen_curve:prime256v1 -out tls.key
openssl req -new -key tls.key -out lab.csr \
-subj '/CN=lab.example.test' \
-addext 'subjectAltName=DNS:lab.example.test'
openssl req -in lab.csr -noout -verify
openssl req -in lab.csr -noout -text
Kỳ vọng self-signature của yêu cầu hợp lệ và Requested Extensions có DNS:lab.example.test. Tài liệu req giải thích -addext. Đây mới là SAN được yêu cầu, chưa phải SAN CA đã chứng nhận. Không gửi tls.key kèm CSR.
Lab bổ sung đã so public key trong CSR với public key xuất từ tls.key, kiểm tra quyền hai khóa là 600 và đạt. Không kiểm thử chuỗi CA, hostname của TLS client, thu hồi hoặc danh tính thật. Kết thúc bằng hủy môi trường dùng một lần; không tái sử dụng các khóa minh họa.
Nếu không đọc được khóa, kiểm tra đường dẫn và quyền trong thư mục lab trước. Nếu xác minh thất bại, giữ bản gốc rồi đối chiếu đúng tệp, đúng public key và đúng chữ ký. Không tắt xác minh để làm phép thử “thành công”. CSR hợp lệ nhưng chưa được CA cấp là trạng thái bình thường ở bước này.
Trước bài mã hóa Web, hãy tự vẽ riêng ba việc: xác minh tên dịch vụ, thiết lập khóa phiên và bảo vệ dữ liệu truyền. Nếu gộp chúng thành một biểu tượng ổ khóa, bạn sẽ khó giải thích đúng nguyên nhân khi kết nối HTTPS báo lỗi.
Học bảo vệ quyền riêng tư qua cookie, fingerprinting, hồ sơ và quyền dữ liệu; thực hành quan sát cookie trong lab riêng, phân biệt xóa cục bộ và log server.
Học giao tiếp an toàn qua phishing, tệp đính kèm, phân loại thông tin và quyền cloud; thực hành xác minh người nhận, giảm dữ liệu và xử lý chia sẻ nhầm.
Hiểu danh tính và xác thực với mật khẩu, MFA, passkeys và SSO; đối chiếu NIST 800-63B-4, thực hành salt và băm, lập đường khôi phục tài khoản phù hợp.
Phân biệt mã hóa mạng và ẩn danh với VPN, proxy, Tor và E2EE; đọc ranh giới bảo vệ, hiểu bút danh blockchain qua bốn tình huống thực hành giả định.