Bài 13: Cryptography Applications (Phần 1)¤
1. Mục tiêu bảo mật (Security Goals)¤
Trước khi đi vào các giao thức, cần hiểu rõ các mục tiêu bảo mật mà hệ thống cần đạt được:
| Mục tiêu | Ý nghĩa |
|---|---|
| Confidentiality | Bảo mật dữ liệu, chỉ người được phép mới đọc được |
| Authentication | Xác minh danh tính người dùng, thiết bị, tiến trình |
| Integrity | Dữ liệu không bị thay đổi trên đường truyền |
| Non-repudiation | Không thể chối bỏ hành động đã thực hiện |
| Availability | Hệ thống luôn sẵn sàng phục vụ |
| Privacy | Bảo vệ thông tin cá nhân |
Mỗi mục tiêu được đảm bảo bởi các cơ chế mật mã khác nhau:
- Cipher systems: DES, AES (đối xứng), RSA, ECC, CRYSTALS-KYBER (bất đối xứng)
- Hash functions: SHA-256, SHA3-512,...
- MAC (Message Authentication Code)
- Chữ ký số / Chứng chỉ số
- Kiểm soát truy cập: RBAC, ABAC, PBAC
2. Giao thức bảo mật mạng – Tổng quan¤
Một giao thức bảo mật mạng hoàn chỉnh phải giải quyết ba vấn đề cốt lõi:
flowchart TD
A[Thiết lập kết nối bảo mật] --> B[1. Authentication\nXác thực danh tính]
A --> C[2. Key Agreement\nThỏa thuận khóa phiên]
A --> D[3. Algorithm Negotiation\nThương lượng thuật toán mã hóa]
B --> E[Kết nối bảo mật]
C --> E
D --> E3. Xác thực (Authentication)¤
3.1 Định nghĩa¤
Định nghĩa Authentication (NIST)
Authentication là quá trình xác minh danh tính của một người dùng, tiến trình hoặc thiết bị, thường là điều kiện tiên quyết để cho phép truy cập vào tài nguyên của hệ thống thông tin.
Quá trình xác thực gồm hai bước:
- Identification: Cung cấp thông tin định danh (tên, ID,...)
- Verification: Hệ thống kiểm tra xem thông tin đó có hợp lệ không
Authorization (Ủy quyền) khác với Authentication: là quyền/phép mà thực thể được cấp để truy cập tài nguyên sau khi đã được xác thực.
3.2 Các yếu tố xác thực (Authentication Factors)¤
Ba nhóm yếu tố xác thực
- Mật khẩu (Password)
- Mã PIN
- Câu hỏi bí mật
- Smartcard
- Thẻ khóa điện tử
- Chứng chỉ số (Digital Certificate)
- Thiết bị của người dùng
- Vân tay (Fingerprint)
- Võng mạc (Retina)
- Khuôn mặt (Face)
- Giọng nói (Voice)
- PUFs (Physical Unclonable Functions)
3.3 Xác thực bằng chứng chỉ số (Certificate-based Authentication)¤
Đây là phương pháp phổ biến nhất để xác thực server/tài nguyên. Ý tưởng cốt lõi:
sequenceDiagram
participant Client
participant Server
participant CA as Trusted CA (PKI)
CA->>Server: Cấp Certificate (chứa Public Key + Identity)
Client->>Server: Yêu cầu kết nối
Server->>Client: Gửi Certificate
Client->>CA: Xác minh chữ ký của CA trên Certificate
CA-->>Client: Hợp lệ → Tin tưởng PKS (Public Key của Server)Chứng chỉ số kết hợp: - Public key của server - Identity của server (IP, tên miền,...) - Chữ ký của CA để xác nhận tính hợp lệ
# Kiểm tra certificate của một website thực tế
openssl s_client -connect facebook.com:443 -showcerts
Hạn chế của Certificate-based Authentication
- Cần hạ tầng PKI (tốn kém, phức tạp)
- Vấn đề Revocation (thu hồi chứng chỉ): Khi chứng chỉ bị lộ, cần cơ chế CRL/OCSP để vô hiệu hóa
- Network Payload tăng do phải truyền certificate
- Trusted CA: Ai tin tưởng CA nào? Vấn đề Semi-Trusted và Zero-Trust
- Nếu CA bị tấn công → toàn bộ hệ thống tin tưởng bị ảnh hưởng
3.4 Xác thực bằng mật khẩu (Password-based Authentication)¤
Quy trình đăng nhập cơ bản:
sequenceDiagram
participant User
participant Server
Note over Server: Lưu trữ: (name, h(pw))
User->>Server: Gửi (name, pw')
Server->>Server: Tìm hàng theo name
Server->>Server: So sánh h(pw') == h(pw)?
Server-->>User: Xác thực thành công / thất bạiCác tấn công vào mật khẩu
1. Dictionary Attack (Tấn công từ điển)
- Con người có xu hướng chọn mật khẩu dễ nhớ → không gian mật khẩu nhỏ
- Kẻ tấn công tạo danh sách các mật khẩu phổ biến, hash tất cả, rồi so sánh với bảng lưu trữ
- Offline Dictionary Attack: Kẻ tấn công lấy được file
/etc/shadow, tấn công offline không giới hạn tốc độ
2. Verification Table Attack
- Nếu server lưu
h(pw)không có salt → kẻ tấn công tạo Rainbow Table (bảng tra cứu hash → plaintext) - Giải pháp: Sử dụng salt (giá trị ngẫu nhiên) trước khi hash: lưu
h(pw || salt)kèmsalt
3.5 Xác thực đa yếu tố (Multi-Factor Authentication – MFA)¤
Kết hợp nhiều yếu tố để tăng độ bảo mật:
| Yếu tố | Lưu trữ | Xác minh |
|---|---|---|
| Biometric | Cần bộ nhớ bảo mật | So sánh 1-1 hay 1-nhiều? |
| Smartcard | Lưu trữ bảo mật trên thẻ | Tự thực hiện thuật toán xác minh |
| TPM/TEE/Secure Enclave | Lưu trữ phần cứng bảo vệ | Thực hiện thuật toán bảo mật |
Câu hỏi: Tại sao cần MFA?
Vì không yếu tố nào là hoàn hảo: - Mật khẩu có thể bị đánh cắp (phishing, keylogger) - Smartcard có thể bị mất - Biometric có thể bị giả mạo (deepfake, spoofing)
Khi kết hợp nhiều yếu tố, kẻ tấn công phải đồng thời vượt qua tất cả → khó hơn rất nhiều.
4. Thỏa thuận khóa phiên (Session Key Agreement)¤
4.1 Tại sao cần khóa phiên?¤
Sau khi xác thực server (qua certificate), client cần thiết lập một khóa phiên bí mật (ssk – session secret key) để mã hóa dữ liệu trao đổi. Khóa này:
- Chỉ tồn tại trong một phiên làm việc
- Được tạo mới mỗi lần kết nối → Perfect Forward Secrecy (PFS)
- Thường dùng mã hóa đối xứng (AES) vì nhanh hơn
4.2 Diffie-Hellman trên ECC (ECDH)¤
Đây là phương pháp phổ biến nhất hiện nay:
sequenceDiagram
participant Client as Client (A)
participant Server as Server (B)
Note over Client,Server: Đã xác minh certificate, biết PKS
Client->>Client: Chọn ngẫu nhiên dA
Client->>Client: Tính QA = dA * G
Client->>Server: Gửi: name, C = E_PKS(QA), tag = h(QA || name)
Server->>Server: Giải mã: DSK_S(C) = QA'
Server->>Server: Xác minh tag = h(QA' || name)
Server->>Server: Chọn ngẫu nhiên dB
Server->>Server: Tính QB = dB * G
Server->>Client: Gửi: QB, tagS = h(dB*QA || name)
Client->>Client: Xác minh tagS = h(dA*QB || name)
Note over Client,Server: ssk = dA*QB = dB*QA = dA*dB*G ✓Tính đúng đắn của ECDH
Sau khi có ssk, mọi dữ liệu được mã hóa đối xứng:
4.3 Xác thực trong môi trường WiFi (Pre-shared Secret)¤
Khi không có chứng chỉ (ví dụ: WiFi gia đình), hai bên sử dụng pre-shared secret (mật khẩu WiFi):
Các giao thức này xây dựng cơ chế xác thực và thỏa thuận khóa dựa trên mật khẩu chung mà không cần PKI.
5. Giao thức bảo mật đa server (Multi-server AKA)¤
5.1 Mục tiêu¤
Trong môi trường thực tế, người dùng cần kết nối với nhiều server khác nhau (D₁, D₂,..., Dₖ). Thay vì đăng ký riêng với từng server, cần:
- Đăng ký một lần (One-time registration)
- Đảm bảo: Xác thực lẫn nhau, Thỏa thuận khóa, Không thể truy vết (Untraceability), Thu hồi (Revocation), Hiệu quả
5.2 Các biến thể giao thức¤
Certificateless AKA – Biometric Multi-server (2016)
- Các yếu tố: Mật khẩu + Smartcard + Sinh trắc học
- Bảo mật dựa trên: Bài toán DLP (
x / y = gˣ), Hash Function, Random Oracle Model - Đặc điểm: Untraceable – server không thể liên kết các phiên của cùng một người dùng
Three-party AKA – ECC-based (2018)
- Kiến trúc: Người dùng ↔ Trusted Server ↔ Server dịch vụ
- Bảo mật dựa trên: Bài toán ECDLP (
d / Q = d*G) - Chứng minh bảo mật: ROR model (Real-or-Random)
SIP Protocol – Multimedia Networks (2018)
- Ứng dụng cho mạng đa phương tiện dựa trên IP (VoIP, video conferencing)
- Session Initiation Protocol với xác thực sinh trắc học
Satellite Mobile Networks (2019)
- Ứng dụng cho mạng vệ tinh di động
- Thách thức: độ trễ cao, tài nguyên hạn chế
6. Triển khai giao thức bảo mật theo tầng mạng¤
6.1 Vị trí triển khai¤
graph TD
A[Application Layer] --> |"PGP, S/MIME (Email)\nHTTPS"| E[Bảo vệ đầu-cuối]
B[Transport Layer] --> |"SSL/TLS, SSH"| F[Bảo vệ TCP/UDP segment]
C[Network Layer] --> |"IPsec, VPN"| G[Bảo vệ IP packet]
D[Data Link Layer] --> |"WEP, WPA, WPA2, WPA3"| H[Bảo vệ frame]6.2 So sánh ưu/nhược điểm¤
| Tầng | Ưu điểm | Nhược điểm |
|---|---|---|
| Application | Bảo vệ đầu-cuối; node trung gian không cần giải mã | Kẻ tấn công vẫn phân tích được header; phải sửa ứng dụng |
| Transport | Không cần sửa ứng dụng; bảo vệ TCP payload | Kẻ tấn công phân tích được IP header |
| Network | Không cần sửa ứng dụng; Transport mode hoặc Tunnel mode | Phức tạp hơn; Tunnel mode cần gateway |
| Data Link | Kẻ tấn công khó phân tích traffic | Chỉ bảo vệ trên một đường link vật lý |
7. Giao thức SSH¤
7.1 Kiến trúc phân lớp¤
┌─────────────────────────────┐
│ SSH Connection │ ← Quản lý nhiều channel (shell, SFTP,...)
├─────────────────────────────┤
│ SSH User Authentication │ ← Xác thực user (password hoặc PKC)
├─────────────────────────────┤
│ SSH Transport │ ← Xác thực server, trao đổi khóa, mã hóa
├─────────────────────────────┤
│ TCP │
├─────────────────────────────┤
│ IP │
└─────────────────────────────┘
7.2 Luồng hoạt động SSH¤
sequenceDiagram
participant C as Client
participant S as Server
C->>S: Yêu cầu kết nối
S->>C: Gửi Public Key Certificate
C->>C: Xác thực CA của server
C->>S: E_pub_S(Danh sách thuật toán hỗ trợ)
S->>C: E_pri_S(Thuật toán được chọn)
C->>S: E_pub_S(Session Key SK)
C->>S: E_pub_S(Username + Password)
S->>C: E_pri_S(Kết quả xác thực)Tại sao SSH quan trọng?
SSH giải quyết vấn đề quản trị máy chủ từ xa một cách bảo mật. Trước khi có SSH, Telnet truyền mọi thứ (kể cả mật khẩu) dưới dạng plaintext — bất kỳ ai nghe lén trên mạng đều đọc được. SSH mã hóa toàn bộ phiên làm việc.
8. Giao thức SSL/TLS¤
8.1 Lịch sử phát triển¤
| Phiên bản | Năm | Trạng thái |
|---|---|---|
| SSL 1.0 | Chưa phát hành | Không dùng |
| SSL 2.0 | 1995 | Deprecated 2011 (RFC 6176) |
| SSL 3.0 | 1996 | Deprecated 2015 (RFC 7568) |
| TLS 1.0 | 1999 | Deprecated 2021 (RFC 8996) |
| TLS 1.1 | 2006 | Deprecated 2021 (RFC 8996) |
| TLS 1.2 | 2008 | Vẫn được dùng |
| TLS 1.3 | 2018 | Khuyến nghị hiện tại |
8.2 Cấu trúc TLS¤
┌──────────────────────────────────────────────────┐
│ HTTP (HTTPS) │
├──────────────┬──────────────────┬────────────────┤
│ SSL Handshake│ Change Cipher │ SSL Alert │
│ Protocol │ Spec Protocol │ Protocol │
├──────────────┴──────────────────┴────────────────┤
│ SSL Record Protocol │
├──────────────────────────────────────────────────┤
│ TCP │
└──────────────────────────────────────────────────┘
8.3 TLS 1.2 Handshake¤
sequenceDiagram
participant C as Client
participant S as Server
C->>S: ClientHello (danh sách cipher suites hỗ trợ)
S->>C: ServerHello (cipher suite được chọn)
S->>C: Certificate + Signature
S->>C: Key Share (ECDHE public key)
C->>C: Xác minh certificate
C->>S: Key Share (client ECDHE public key)
Note over C,S: Cả hai tính toán session key
S->>C: Finished
C->>S: Finished
C->>S: HTTP GET
S->>C: HTTP ResponseBa thành phần chính của TLS 1.2: 1. Authentication: Digital certificate (PKI) 2. Key Agreement: ECDH 3. Algorithm Negotiation: Thỏa thuận cipher suite (AES-128-CBC, SHA256, v.v.)
8.4 TLS 1.3 – Cải tiến so với 1.2¤
TLS 1.3 (RFC 8446) giảm số lần RTT (Round-Trip Time):
sequenceDiagram
participant C as Client
participant S as Server
C->>S: ClientHello + key_share + signature_algorithms + psk_key_exchange_modes
Note right of S: Key Exchange phase
S->>C: ServerHello + key_share
S->>C: {EncryptedExtensions} + {Certificate} + {CertificateVerify} + {Finished}
Note over C,S: Application Data có thể bắt đầu sớm hơn!
C->>S: {Certificate} + {CertificateVerify} + {Finished}
C->>S: [Application Data]TLS 1.3 cải tiến gì so với 1.2?
- 1-RTT thay vì 2-RTT cho full handshake
- 0-RTT (Early Data) cho phép gửi data ngay trong handshake (với PSK)
- Loại bỏ các thuật toán yếu: RSA key exchange, RC4, DES, SHA-1
- Forward Secrecy bắt buộc (chỉ dùng (EC)DHE)
- Mã hóa nhiều phần hơn trong handshake
9. Giao thức IPsec¤
9.1 Tổng quan¤
IPsec (IP Security) là bộ giao thức hoạt động ở tầng Network, mã hóa và/hoặc xác thực các gói IP. Gồm ba giao thức thành phần:
graph TD
IPsec --> AH[Authentication Header - AH\nXác thực nguồn gốc + toàn vẹn\nPhát hiện replay attack]
IPsec --> ESP[Encapsulating Security Payload - ESP\nMã hóa và/hoặc xác thực]
IPsec --> IKE[Internet Key Exchange - IKE\nThiết lập khóa bí mật]9.2 Hai chế độ hoạt động¤
Transport Mode – Bảo vệ host-to-host:
Các endpoint phải là IPsec-aware. Thường dùng cho kết nối trực tiếp giữa hai host.
Tunnel Mode – Yêu cầu gateway:
Gateway đóng gói toàn bộ gói IP gốc → bảo vệ cả header nội bộ.
graph LR
A[Remote Host] -->|Outer Tunnel| B[Security Gateway]
B -->|Inner Tunnel| C[Internal Server]
style B fill:#f9f,stroke:#3339.3 Security Association (SA)¤
SA là gì?
SA (Security Association) là một thỏa thuận một chiều giữa hai bên về các tham số bảo mật sẽ sử dụng. Mỗi SA chỉ phục vụ một chiều và một mục đích (hoặc mã hóa, hoặc xác thực).
→ Nếu cần cả hai: tạo hai SA riêng biệt.
Ba tham số định danh một SA: 1. SPI – Security Parameters Index 2. IP Destination Address 3. Security Protocol Identifier (AH hay ESP)
Hai cơ sở dữ liệu quan trọng: - SAD (Security Association Database): Lưu các SA đang hoạt động - SPD (Security Policy Database): Quy tắc áp dụng SA cho gói tin nào
9.4 Authentication Header (AH)¤
┌─────────────┬──────────────┬────────────────────────────┐
│ Next Header │ Payload Len │ RESERVED │
├─────────────┴──────────────┴────────────────────────────┤
│ Security Parameters Index (SPI) │
├──────────────────────────────────────────────────────────┤
│ Sequence Number │
├──────────────────────────────────────────────────────────┤
│ Integrity Check Value (ICV) – variable │
└──────────────────────────────────────────────────────────┘
9.5 Chống Replay Attack bằng Sliding Window¤
- Vùng A: Sequence number quá nhỏ → Loại bỏ
- Vùng B: Trong cửa sổ → Kiểm tra xem đã nhận chưa (bitmap)
- Vùng C: Sequence number mới → Dịch cửa sổ và chấp nhận
Tại sao cần chống Replay Attack?
Kẻ tấn công có thể bắt các gói tin đã được xác thực hợp lệ và gửi lại nhiều lần (ví dụ: gói tin "chuyển tiền 100$"). Sequence number + sliding window đảm bảo mỗi gói chỉ được xử lý một lần.
9.6 Encapsulated Security Payload (ESP)¤
┌──────────────────────────────────────────────────────────┐
│ Security Parameters Index (SPI) │
├──────────────────────────────────────────────────────────┤
│ Sequence Number │
├──────────────────────────────────────────────────────────┤
│ Payload Data (variable length) │◄─ Mã hóa
├──────────────────────────────────────────────────────────┤
│ Padding (0-255 bytes) | Pad Len | Next Hdr │◄─ Mã hóa
├──────────────────────────────────────────────────────────┤
│ Authentication Data (variable length) │◄─ MAC
└──────────────────────────────────────────────────────────┘
ESP trong Transport Mode vs Tunnel Mode:
Transport Mode:
[IP Hdr | ESP Hdr | TCP/UDP/... | ESP Trlr | ESP Auth]
|←── Mã hóa ──→|
|←────────── MAC ──────────────────→|
Tunnel Mode:
[Outer IP | ESP Hdr | Inner IP | Payload | ESP Trlr | ESP Auth]
|←────── Mã hóa ────────→|
|←──────────────── MAC ───────────────────→|
9.7 Quản lý khóa – Oakley KDP và ISAKMP¤
Oakley Key Determination Protocol là Diffie-Hellman có tăng cường:
| Tính năng | Mục đích |
|---|---|
| DH cơ bản | Thiết lập khóa bí mật chung |
| + Authentication | Chống tấn công Man-in-the-Middle |
| + Cookies | Chống tấn công Clogging (DoS) |
| + Nonce | Chống Replay Attack |
Clogging Attack là gì?
Kẻ tấn công gửi hàng loạt gói tin với các giá trị Yi giả mạo, buộc server phải liên tục tính Ki = Yi^X mod p – phép tính modular exponentiation rất tốn CPU → DoS.
Giải pháp Cookie: Trước khi tính DH, server gửi cookie ngẫu nhiên về source address và chờ xác nhận. Nếu source address giả mạo → không nhận được cookie → không gửi xác nhận được → server không tính toán.
ISAKMP (Internet Security Association and Key Management Protocol) định nghĩa format của các message trao đổi:
┌────────────────┬────────────────┐
│ 64-bit Initiator Cookie │
├────────────────┬────────────────┤
│ 64-bit Responder Cookie │
├──────┬──────┬──┴───┬────────────┤
│Next │Major │Minor │ Exchange │
│Pload │ Ver │ Ver │ Type │
├──────┴──────┴──────┴────────────┤
│ 32-bit Message ID │
├─────────────────────────────────┤
│ 32-bit Length │
└─────────────────────────────────┘
Các loại payload ISAKMP hỗ trợ: SA, Proposal, Transform, Key-exchange, Identification, Certificate, Hash, Signature, Nonce, Notification, Delete,...
10. Tổng kết – Bức tranh toàn cảnh¤
graph TB
subgraph "Tầng ứng dụng"
A1[PGP / S/MIME] --> A2[Email Security]
A3[HTTPS] --> A4[Web Security]
end
subgraph "Tầng Transport"
B1[SSL/TLS 1.2 / 1.3] --> B2[Web, API]
B3[SSH] --> B4[Remote Admin]
end
subgraph "Tầng Network"
C1[IPsec AH+ESP+IKE] --> C2[VPN, Site-to-site]
end
subgraph "Tầng Data Link"
D1[WEP / WPA / WPA2 / WPA3] --> D2[WiFi Security]
end
subgraph "Cơ chế nền tảng"
E1[Authentication\nCertificate / Password / MFA]
E2[Key Agreement\nECDH / DH]
E3[Algorithm Negotiation\nAES, SHA, ...]
E4[Cryptographic Primitives\nRSA, ECC, AES, SHA]
end
E1 & E2 & E3 & E4 --> B1
E1 & E2 & E3 & E4 --> C1
E1 & E2 & E3 & E4 --> B3Điểm cần nhớ
- Mọi giao thức bảo mật đều giải quyết 3 bài toán: Xác thực – Thỏa thuận khóa – Thương lượng thuật toán
- TLS 1.3 là tiêu chuẩn hiện đại nhất cho bảo mật tầng Transport
- IPsec hoạt động ở tầng Network, phù hợp cho VPN
- SSH = Transport + User Auth + Connection, dùng cho quản trị từ xa
- Certificate = Public Key + Identity + CA Signature → nền tảng của PKI
- SA trong IPsec là một chiều, một mục đích → cần 2 SA cho mã hóa hai chiều