SSCP Domain 5 · 10%

Mật mã học

Cryptography

Nền tảng toán học của bảo mật thông tin: symmetric/asymmetric encryption, hash functions, PKI, TLS 1.3 handshake và quản lý vòng đời khóa — từ lý thuyết đến thực hành với OpenSSL.

Mục tiêu chương / Learning objectives

1. Lý thuyết cốt lõi / Core theory

1.1. Ba trụ cột mật mã học (Symmetric / Asymmetric / Hash)

Symmetric (Đối xứng): Cùng một khóa để mã hóa và giải mã. Nhanh, phù hợp với dữ liệu lớn. Vấn đề: phân phối khóa an toàn (key distribution problem). Thuật toán: AES-128/256 (block cipher, chuẩn công nghiệp hiện tại); AES-GCM (Galois/Counter Mode — vừa mã hóa vừa authentication, authenticated encryption); 3DES (legacy — không dùng mới).

Asymmetric (Bất đối xứng): Cặp khóa public/private. Public key mã hóa, private key giải mã (hoặc ngược lại cho chữ ký số). Chậm hơn symmetric (~1000x) nên chỉ dùng để trao đổi khóa symmetric hoặc ký số. Thuật toán: RSA (2048-bit tối thiểu, 4096-bit recommended); ECC (Elliptic Curve — key nhỏ hơn RSA nhưng bảo mật tương đương, hiệu quả hơn trên mobile/IoT); Diffie-Hellman (key exchange — hai bên tạo shared secret qua kênh công khai mà không truyền khóa).

Hash (Hàm băm): One-way function — không thể đảo ngược. Dùng để kiểm tra tính toàn vẹn. MD5 (128-bit, broken — không dùng bảo mật); SHA-1 (160-bit, deprecated); SHA-256/SHA-3 (chuẩn hiện tại). Collision resistance: không thể tìm được hai input khác nhau cho cùng hash output.

1.2. Chữ ký số & PKI (Digital Signature & PKI)

Chữ ký số: Hash của message được mã hóa bằng private key của người gửi. Người nhận dùng public key giải mã, so sánh với hash của message nhận được — xác minh authenticity (ai ký) và integrity (không bị thay đổi).

PKI Architecture: Root CA (tự ký, offline, cực kỳ được bảo vệ) → Intermediate/Issuing CA (ký certificate cho end-entities) → End-entity Certificate (website, user, device). CRL (Certificate Revocation List): danh sách certificate bị thu hồi, tải về định kỳ. OCSP (Online Certificate Status Protocol): kiểm tra real-time trạng thái certificate — nhanh hơn CRL. Certificate Pinning: ứng dụng chỉ tin một certificate/public key cụ thể — chống MITM ngay cả khi CA bị compromise.

Certificate Chain of Trust: Browser tin Root CA → Root CA ký Intermediate CA certificate → Intermediate CA ký website certificate. Khi truy cập HTTPS, browser xác minh toàn bộ chuỗi từ website certificate ngược lên Root CA đã được pre-installed. "Chain of trust" đứt tại bất kỳ đâu = certificate error.

1.3. TLS 1.3 Handshake

TLS 1.3 rút gọn handshake xuống còn 1-RTT (Round Trip Time) thay vì 2-RTT của TLS 1.2:

  1. ClientHello: Client gửi supported cipher suites, key share (Diffie-Hellman public key), extensions.
  2. ServerHello: Server chọn cipher suite, gửi key share của mình, certificate, và Finished trong cùng một message.
  3. Client Finished: Client xác minh certificate, tính toán session key, gửi Finished. Từ đây dữ liệu được mã hóa.

TLS 1.3 loại bỏ RSA key exchange (không có forward secrecy), chỉ giữ ECDHE/DHE (đảm bảo forward secrecy — compromise private key sau này không giải mã được traffic cũ).

1.4. Quản lý vòng đời khóa (Key Management Lifecycle)

5 giai đoạn: Generation (tạo khóa với entropy đủ mạnh — CSPRNG); Distribution (phân phối an toàn — thường qua asymmetric encryption hoặc key ceremony); Storage (lưu trong HSM — Hardware Security Module, hoặc key vault như Azure Key Vault/HashiCorp Vault); Rotation (đổi khóa định kỳ theo policy — thường 1–2 năm); Revocation & Destruction (thu hồi khi compromise, hủy an toàn theo NIST SP 800-88).

1.5. Post-Quantum Cryptography (PQC) — Mối đe dọa lượng tử

Máy tính lượng tử với thuật toán Shor's algorithm có thể phá RSA và ECC trong thời gian đa thức — đe dọa toàn bộ PKI và TLS hiện tại. NIST đã chuẩn hóa năm 2024 ba tiêu chuẩn PQC chính thức:

Hash functions (SHA-256/SHA-3) và AES-256 vẫn an toàn trước lượng tử — Grover's algorithm chỉ giảm hiệu quả một nửa, tương đương giảm key size từ 256-bit xuống 128-bit, vẫn đủ mạnh.

Tấn công "Thu thập ngay, giải mã sau" ("Harvest Now, Decrypt Later")

Đối thủ có thể thu thập và lưu trữ traffic mã hóa ngay hôm nay, chờ đến khi máy tính lượng tử đủ mạnh để giải mã. Dữ liệu có giá trị lâu dài (bí mật quốc gia, hồ sơ y tế, IP) đang bị rủi ro ngay cả khi chưa có quantum computer thực sự. Đây là lý do tổ chức phải bắt đầu di chuyển sang PQC ngay bây giờ, không phải khi quantum computer xuất hiện.

Chiến lược di chuyển sang PQC (Migration Strategy)

2. Bài thực hành / Hands-on labs

🖥️ Nền tảng / Platform: Windows 11 + Ubuntu 22.04 LTS
🛠️ Công cụ / Tools: PowerShell 7, Bash + OpenSSL 3.x

Lab 1 — Kiểm tra Certificate và TLS (PowerShell)

OS: Windows 11 · Tool: PowerShell 7

# Xem certificate trong Local Machine store
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter |
    Format-Table -AutoSize

# Certificate sắp hết hạn trong 90 ngày — cần gia hạn ngay
Get-ChildItem Cert:\LocalMachine\Root |
    Where-Object { $_.NotAfter -lt (Get-Date).AddDays(90) } |
    Select-Object Subject, NotAfter, Thumbprint |
    Format-Table -AutoSize

# Kiểm tra TLS version và cipher suite của một website
$tcpClient = New-Object System.Net.Sockets.TcpClient("google.com", 443)
$sslStream = New-Object System.Net.Security.SslStream($tcpClient.GetStream(), $false,
    { param($sender, $cert, $chain, $errors) $true })
$sslStream.AuthenticateAsClient("google.com")
Write-Host "TLS Version : $($sslStream.SslProtocol)"
Write-Host "Cipher Suite: $($sslStream.CipherAlgorithm) $($sslStream.CipherStrength)-bit"
Write-Host "Hash Algo   : $($sslStream.HashAlgorithm)"
$sslStream.Close()
$tcpClient.Close()

# Certificate chain của website
$webRequest = [System.Net.WebRequest]::Create("https://google.com")
$webRequest.GetResponse() | Out-Null
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new(
    $webRequest.ServicePoint.Certificate)
Write-Host "Subject: $($cert.Subject)"
Write-Host "Issuer : $($cert.Issuer)"
Write-Host "Expires: $($cert.NotAfter)"

✅ Kết quả mong đợi / Expected output: TLS Version: Tls13 (hoặc Tls12 tùy server). Cipher Suite: Aes256 256-bit. Certificate của google.com với Issuer là Google Trust Services Intermediate CA. Certificate hết hạn trong <90 ngày cần alert ngay — expired certificate = dịch vụ down đột ngột.

Lab 2 — PKI thực hành với OpenSSL (Ubuntu 22.04)

OS: Ubuntu 22.04 · Tool: Bash + OpenSSL 3.x (sudo apt install openssl -y)

# BƯỚC 1: Tạo RSA 2048-bit private key
openssl genrsa -out mykey.pem 2048
# Xem cấu trúc key
openssl rsa -in mykey.pem -text -noout | head -20

# BƯỚC 2: Xuất public key từ private key
openssl rsa -in mykey.pem -pubout -out pubkey.pem
cat pubkey.pem

# BƯỚC 3: Tạo self-signed certificate (1 năm)
openssl req -new -x509 -key mykey.pem -out cert.pem -days 365 \
    -subj "/C=VN/ST=HoChiMinh/O=HoaTranLab/CN=hoatranlab.io.vn"

# BƯỚC 4: Xem thông tin certificate
openssl x509 -in cert.pem -text -noout | grep -E "Subject|Issuer|Not|Algorithm|Public"

# BƯỚC 5: Tạo chữ ký số cho file
echo "Tai lieu quan trong - v1.0" > testfile.txt
openssl dgst -sha256 -sign mykey.pem -out sig.bin testfile.txt
echo "File signed. Signature size: $(wc -c < sig.bin) bytes"

# BƯỚC 6: Xác minh chữ ký số
openssl dgst -sha256 -verify pubkey.pem -signature sig.bin testfile.txt

# BƯỚC 7: Demo hash integrity
echo "original content" | sha256sum
echo "original content" | sha256sum  # Cùng output = deterministic
echo "Original content" | sha256sum  # Khác 1 ký tự = hash hoàn toàn khác (avalanche effect)

✅ Kết quả mong đợi / Expected output: Bước 6 in ra Verified OK — xác nhận chữ ký hợp lệ. Nếu thay đổi nội dung file rồi verify lại → Verification failure — minh họa tính toàn vẹn. Bước 7 cho thấy "original" và "Original" có hash SHA-256 hoàn toàn khác nhau — avalanche effect của hàm băm mật mã.

3. Tình huống doanh nghiệp / Real-world scenario

Bối cảnh:

Lúc 9:00 sáng, tất cả user báo lỗi "Your connection is not private" khi truy cập web portal nội bộ. Monitoring alert: TLS certificate của portal.company.com đã hết hạn từ tối hôm qua. Dịch vụ này phục vụ 500 nhân viên cho nghiệp vụ hàng ngày.

Giải quyết và phòng ngừa:

  1. Emergency fix (30 phút): Gia hạn certificate qua CA hoặc dùng Let's Encrypt certbot renew --force. Restart web server. Verify bằng openssl s_client -connect portal.company.com:443 | openssl x509 -noout -dates.
  2. Root cause: Certificate monitoring chưa được thiết lập. Không có alert tự động khi certificate sắp hết hạn.
  3. Prevention — Key Management Lifecycle: Thiết lập monitoring alert 90/60/30 ngày trước expiry. Ưu tiên auto-renewal (ACME protocol / Let's Encrypt). Ghi toàn bộ certificate vào CMDB với ngày hết hạn.
  4. Audit: Quét toàn bộ certificate nội bộ — dùng PowerShell script hoặc công cụ như Venafi/Keyfactor để có visibility đầy đủ.

Bài học: Certificate expiry là nguyên nhân downtime có thể phòng ngừa 100%. "We forgot to renew" là failure of key management process, không phải failure of cryptography.

4. Tự kiểm tra / Knowledge check

  1. Tại sao không dùng asymmetric encryption để mã hóa toàn bộ dữ liệu lớn? Giải pháp thực tế là gì?
  2. Forward Secrecy (Perfect Forward Secrecy) bảo vệ điều gì? TLS 1.3 đạt được nhờ cơ chế nào?
  3. Phân biệt CRL và OCSP. OCSP Stapling giải quyết vấn đề gì của OCSP thông thường?
  4. SHA-256 và AES-256 có đủ bảo mật trước máy tính lượng tử không? Giải thích tại sao.
  5. Trong key management lifecycle, tại sao giai đoạn "Destruction" (hủy khóa) quan trọng?
C04: Xử lý sự cố & Phục hồi Chương 6: An ninh mạng & Truyền thông
Thực hành trên công cụPowerShell 7 · Bash · OpenSSL 3.x
Nền tảngWindows 11 · Ubuntu 22.04
Thời điểm phát hànhQ2/2026
Ngày biên soạn24/05/2026
Người biên soạnTrần Văn Hòa (MCT)
Phiên bảnv1.0
Zalo