Mã hóa và Diffie Hellman

[dangquangminh]

Anh em kỹ sư mạng chắc ai cũng từng nghe câu “hệ thống bảo mật mạnh đến đâu còn phụ thuộc vào cái khóa” — và đúng vậy, khi triển khai IPsec hay bất kỳ hệ thống VPN nào, việc chọn thuật toán mã hóa và cơ chế trao đổi khóa là một trong những quyết định sống còn.

Bởi vì trong bảo mật, không phải chỉ “mã hóa” là đủ. Chúng ta phải chọn thuật toán đã được cộng đồng mật mã kiểm chứng và có khả năng chống lại các cuộc tấn công brute-force trong thời gian đủ dài để dữ liệu trở nên vô giá trị với kẻ tấn công.

---

1. Thuật toán mã hóa trong IPsec

DES

• Loại: Đối xứng (Symmetric)
• Khóa: 56-bit
• Ưu điểm: Từng rất phổ biến, hiệu suất cao thời kỳ ra đời.
• Nhược điểm: Ngày nay quá yếu, có thể brute-force trong vài giờ với phần cứng hiện đại.
• Tình trạng: Đã lỗi thời, hầu như không dùng cho VPN bảo mật nghiêm túc.

3DES

• Loại: Đối xứng
• Cơ chế: Mã hóa mỗi khối 64-bit 3 lần với 3 khóa 56-bit độc lập.
• Ưu điểm: Mạnh hơn DES nhiều lần.
• Nhược điểm: Chậm hơn AES đáng kể, tiêu tốn CPU.
• Tình trạng: Vẫn được hỗ trợ nhưng dần bị thay thế.

AES

• Loại: Đối xứng, chuẩn NIST.
• Khóa: 128-bit, 192-bit, 256-bit.
• Ưu điểm: Nhanh hơn DES/3DES, mạnh hơn, đặc biệt hiệu quả khi chạy trên phần cứng hoặc phần mềm tối ưu.
• Thực tế: Trong IPsec hiện đại, AES là lựa chọn số 1 cho hiệu năng cao và bảo mật lâu dài.

RSA

• Loại: Bất đối xứng (Asymmetric).
• Khóa: 1024-bit trở lên (thường khuyến nghị ≥ 2048-bit).
• Công dụng trong IPsec: Chỉ dùng trong giai đoạn IKE xác thực peer, không dùng để mã hóa dữ liệu vì quá chậm.

SEAL

• Loại: Mã dòng (Stream cipher).
• Khóa: 160-bit.
• Đặc điểm: Tối ưu hóa cho phần mềm, ít dùng phổ biến so với AES.

💡 Kinh nghiệm thực tế: Nếu triển khai VPN cho doanh nghiệp, hãy chọn AES-256 cho dữ liệu nhạy cảm, AES-128 khi muốn cân bằng bảo mật và hiệu năng. Tránh hoàn toàn DES và hạn chế 3DES nếu không bắt buộc.

---

2. Quản lý và trao đổi khóa trong IPsec


Các thuật toán đối xứng như AES cần một khóa bí mật chung. Gửi khóa này qua email hay USB là công thức “tự sát” vì rủi ro bị chặn hoặc sao chép.

Giải pháp là trao đổi khóa công khai (Public Key Exchange), trong đó khóa chung được sinh ra động trong lúc kết nối, và chỉ hai bên biết, ngay cả khi truyền qua kênh không an toàn. Diffie–Hellman (DH)

• Tạo ra một shared secret giữa hai bên.
• Không truyền khóa trực tiếp mà dùng toán học để cả hai bên tự tính ra cùng một giá trị.

Elliptic Curve Diffie–Hellman (ECDH)

• Phiên bản DH dùng mật mã đường cong Elliptic (ECC).
• Bảo mật mạnh hơn với độ dài khóa ngắn hơn, tiết kiệm CPU.

---

3. Nhóm DH và độ mạnh bảo mật


Trong IPsec, “Group” là các thông số toán học (độ lớn số nguyên tố hoặc đường cong Elliptic) quyết định độ khó bẻ khóa:

• DH1: 768-bit — yếu, không dùng.
• DH2: 1024-bit — tối thiểu cho an toàn cơ bản.
• DH5: 1536-bit — mạnh hơn, vẫn dùng trong một số hệ thống cũ.
• DH14: 2048-bit — chuẩn khuyến nghị hiện nay.
• DH15: 3072-bit — bảo mật rất mạnh, CPU tốn hơn.
• DH16: 4096-bit — cực mạnh, dùng cho dữ liệu tối mật.
• DH19: 256-bit ECDH — bảo mật tương đương DH14 nhưng nhẹ hơn.
• DH20: 384-bit ECDH — bảo mật tương đương DH15.
• DH24: 2048-bit ECDH — bảo mật rất cao, dùng cho hệ thống critical.

💡 Kinh nghiệm thực tế:

• Nếu thiết bị hỗ trợ, DH14 hoặc ECDH (DH19) là lựa chọn cân bằng bảo mật và hiệu năng.
• Với VPN cho hệ thống Chính phủ, Tài chính, Quân sự → ưu tiên DH20 hoặc DH24.

---

4. Lời kết cho anh em triển khai IPsec

• AES là chuẩn vàng, DES/3DES nên đưa vào “bảo tàng”.
• RSA chỉ để xác thực, không dùng để mã hóa bulk data.
• DH/ECDH là trái tim của bảo mật khóa — đừng tiếc CPU khi chọn nhóm mạnh.
• Triển khai trên môi trường production cần test kỹ hiệu năng vì nhóm DH lớn và AES-256 sẽ tốn CPU hơn nhiều.