Wireguard một giao thức VPN hiệu năng cao
GIỚI THIỆU VỀ WIREGUARD
Mã nguồn WireGuard được phát triển bởi Jason A. Donenfeld, với bản phát hành đầu tiên vào ngày 09/12/2016. Giải pháp này sử dụng một giao thức VPN mới với các thành phần mật mã hiện đại (ví dụ như ChaCha20-Poly1305, Curve25519, HKDF…), cùng với các bộ quy tắc giúp đảm bảo an toàn, và tốc độ vượt trội hơn khá nhiều so với các giao thức bảo mật đường truyền phổ biến hiện nay như IPSec, TLS, OpenVPN. WireGuard có một ưu điểm là dễ sử dụng, trong khi nhiều giao thức khác như OpenVPN hay IPSec đều có hàng trăm nghìn dòng mã thì WireGuard có mã nguồn mở với chỉ khoảng 4000 dòng mã (cho tới thời điểm hiện tại), điều này có thể sẽ dẫn đến ít lỗi và giúp việc kiểm tra các vấn đề bảo mật được dễ dàng hơn.
WireGuard ban đầu được phát hành cho nhân Linux, nhưng hiện đã được phát triển đa nền tảng hệ điều hành khác nhau (Windows, MacOS, BSD, iOS, Android…) và có thể triển khai rộng rãi.
WireGuard sử dụng các phiên ngắn hạn với các khóa tạm thời để đảm bảo bí mật chuyển tiếp (perfect forward secrecy).
CÁC THUẬT TOÁN MẬT MÃ SỬ DỤNG TRONG GIAO THỨC WIREGUARD
Trong tài liệu mô tả, quá trình tính toán và định dạng các thông báo được trao đổi trong giao thức WireGuard sẽ sử dụng các thuật toán có độ an toàn cao và loại bỏ các thuật toán có đánh giá an toàn thấp. Sau đây là một số thuật toán mật mã chính được sử dụng trong WireGuard và một số đánh giá về độ an toàn tương ứng.
ChaCha20-Poly1305
Mã hóa xác thực ChaCha20-Poly1305 được sử dụng trong cấu trúc mã hóa xác thực với dữ liệu bổ sung (Authenticated Encryption with Additional Data - AEAD). ChaCha20-Poly1305 sử dụng để đảm bảo tính xác thực và tính bảo mật của dữ liệu cần được bảo vệ trên kênh truyền ở cả giai đoạn thỏa thuận khóa và giai đoạn truyền dữ liệu.
Dựa trên đánh giá một số tấn công của Porcter đã được giới thiệu trong tài liệu [1], độ an toàn của ChaCha20-Poly1305 được đánh giá là an toàn.
Curve25519
Curve25519 là một hàm Elliptic Curve DiffieHellman (ECDH). So với các hàm ECDH khác, nó có kích thước khóa khá nhỏ và các yêu cầu đơn giản hơn liên quan đến việc xác nhận khóa.
Curve25519 được sử dụng trong giao thức thỏa thuận khóa của WireGuard. Với Curve25519 thì các tấn công vào thuật toán này đều rất tốn kém theo tài liệu [2]. Tính bảo mật của Curve25519 được thể hiện trong RFC 7748 [3].
HKDF
HKDF (HMAC-based Extract-and-Expand Key Derivation Function) là một hàm có chức năng dẫn xuất khóa dựa trên HMAC. HKDF được dùng trong WireGuard cho phép dẫn xuất ra một hoặc nhiều khóa, mỗi khóa có độ dài 32 byte.
HKDF được sử dụng trong giao thức thỏa thuận khóa Ikpsk2 để dẫn xuất ra chuỗi khóa sử dụng trong WireGuard. Tính bảo mật của HKDF được chứng minh trong tài liệu [4].
BLAKE2
BLAKE2s là một hàm băm mật mã được sử dụng bởi HKDF và dưới dạng mã xác thực thông báo (MAC). Độ an toàn của thuật toán này được chấp nhận trong RFC 7693 [5] và tài liệu Analysis of BLAKE2 [6].
SipHash2-4
SipHash2-4 là một hàm sinh số giả ngẫu nhiên được sử dụng để sinh khóa cho hàm băm mật mã trong WireGuard [7]. Độ an toàn của thuật toán này đã được phân tích và chấp nhận trong tài liệu [8].
QUẢN LÝ KHÓA VÀ PHIÊN TRONG WIREGUARD
Trong triển khai, WireGuard đưa ra một số ràng buộc trong vấn đề quản lý khóa và phiên trong quá trình hoạt động. Dưới đây là bộ quy tắc đã được hệ thống hóa [9]:
Sessions expire: Một phiên không hợp lệ sau 3 phút hoặc sau khi truyền 264 - 24 - 1 gói. Các gói nhận được từ các phiên không hợp lệ sẽ bị loại bỏ.
Rekey rate limit: Bắt đầu bắt tay không bao giờ được gửi hai lần trong vòng 5 giây để tránh quá tải. Giới hạn này chỉ được thực thi ở bên khởi tạo và bao gồm các lần khởi động lại do cookie. Do đó, thiết lập một phiên trong khi một máy chủ sử dụng cookie mất ít nhất 5 giây.
Handshake retransmission: Quá trình bắt đầu bắt tay được thử lại sau 5 giây nếu không có phiên nào được thiết lập (với bên khởi tạo tính từ thời điểm nhận được gói tin handshake response hợp lệ, với bên phản hồi tính từ thời điểm nhận được gói tin Transport đầu tiên). Điều này được giới hạn trong 18 lần thử lại (90 giây), sau đó máy chủ sẽ từ bỏ và loại bỏ tất cả các gói dữ liệu được xếp hàng đợi.
Keepalives: Cả hai máy chủ sau khi nhận được một gói dữ liệu không rỗng, đảm bảo rằng chúng sẽ gửi lại một gói trong vòng 10 giây (thời gian lưu giữ). Phản hồi này có thể là một gói dữ liệu thực được tạo bởi một ứng dụng hoặc nếu bộ hẹn giờ 10 giây hết hạn có thể là một gói rỗng “keepalive” (vẫn được xác thực và mã hóa). Ngược lại, nếu một máy ngang hàng không nhận được phản hồi sau khi gửi một gói dữ liệu không rỗng trong hơn thời gian lưu trữ cộng với thời gian chờ Rekey (tổng cộng 15 giây) thì nó giả sử kết nối bị hỏng và khởi động lại bắt tay để thiết lập lại một phiên.
Session keys storage: Luôn có hai khóa phiên tại một thời điểm. Một khóa là phiên được xác nhận hiện tại, mới nhất. Thứ hai là khóa chưa được xác nhận tiếp theo (như người nhận trong một quá trình bắt tay đang diễn ra) hoặc là khóa phiên trước đó (để cho phép nhận các thông báo không theo thứ tự).
Clearing data: Sau 9 phút (3 lần thời gian chờ của phiên), nếu không có phiên mới nào được tạo hoặc bắt đầu, tất cả các khóa sẽ bị xóa.
Optional persistent keepalive: WireGuard thường không thiết lập phiên nếu không có dữ liệu nào được gửi. Người dùng có thể tùy chọn kích hoạt keepalive liên tục, theo định kỳ sẽ gửi một gói keepalive bất kể dữ liệu để giữ cho đường hầm hoạt động mọi lúc. Điều này có thể cần thiết để duy trì một phiên NAT tồn tại.
HOẠT ĐỘNG CỦA WIREGUARD
Một mục tiêu thiết kế của WireGuard là tránh lưu trữ bất kỳ trạng thái nào trước khi xác thực và không gửi bất kỳ phản hồi nào khi các gói chưa được xác thực. Không có trạng thái nào được lưu trữ cho các gói chưa được xác thực và không có phản hồi nào được tạo, WireGuard vô hình đối với các máy quét mạng và ngang hàng bất hợp pháp. Một số lớp tấn công được tránh bằng cách không chấp nhận các gói chưa được xác thực ảnh hưởng đến bất kỳ trạng thái nào [9].
Mỗi phiên bắt đầu bằng một quá trình bắt tay dựa trên giao thức Noise Ikpsk2 [8] (Immediately Known preshared symmetric key) là một biến thể của khuôn giao thức Noise được WireGuard sử dụng trong quá trình bắt tay để cung cấp xác thực lẫn nhau, thỏa thuận khóa [9].
Quá trình bắt tay trao đổi khóa 1-RTT được thực hiện trước khi bắt đầu gửi các gói dữ liệu được mã hóa. Người khởi tạo gửi một thông báo đến người phản hồi và người phản hồi cũng sẽ gửi lại một thông báo cho người khởi tạo. Sau khi nhận được thông báo phản hồi, cả người khởi tạo và người phản hồi đã có thể tính toán được một chuỗi các khóa. Chuỗi khóa này được sử dụng để bảo vệ dữ liệu ở giai đoạn tiếp theo (truyền dữ liệu, bắt tay lại…). Một số chế độ bắt tay tùy chọn cũng đã được WireGuard đưa ra để có thể đạt được sự linh hoạt trong triển khai.
Độ an toàn của giao thức bắt tay được sử dụng trong WireGuard đã được phân tích và khẳng định trong tài liệu [10] và [11].
Sau khi kết thúc quá trình bắt tay, hai bên truyền thông bắt đầu chuyển sang giai đoạn truyền dữ liệu. Dựa trên các khóa đã thỏa thuận được ở giai đoạn bắt tay, dữ liệu trao đổi giữa hai bên sẽ được bảo vệ bằng thuật toán mã hóa có xác thực ChaCha20-Poly1305. Trong triển khai, cơ chế quản lý khóa và phiên sẽ được sử dụng nhằm đảm bảo an toàn cho dữ liệu và hiệu quả hoạt động của WireGuard.
Thiết kế giao thức và các lựa chọn thực tế trong triển khai đã mang lại cho WireGuard khá nhiều ưu điểm, các ưu điểm này đã được phân tích trong [12], [7], [10], [11].
HIỆU NĂNG CỦA WIREGUARD
Kết quả đã được công bố Theo công bố trong tài liệu [9]: WireGuard được đánh giá cùng với IPsec ở hai chế độ và OpenVPN, sử dụng iperf3 để đo kết quả trung bình trong thời gian hơn ba mươi phút, kết quả như sau:
Hình 1. Tốc độ truyền dữ liệu của OpenVPN, IPSec, WireGuard
Hình 2. Tốc độ phải hồi của OpenVPN, IPSec, WireGuard
Kết quả thí nghiệm về tốc độ truyền dữ liệu cũng cho thấy WireGuard có thể đạt tới giới hạn của Ethernet gigabit, nhỉnh hơn so với IPSec và vượt trội hơn so với OpenVPN. Tốc độ phản hồi thấp của WireGuard trong thí nghiệm kiểm tra độ phản hồi cũng đã thể hiện được về ưu điểm của WireGuard so với IPSec và OpenVPN.
Hình 3. Tốc độ truyền dữ liệu khi sử dụng Wireguard
Hình 4. Tốc độ truyền dữ liệu khi sử dụng OpenVPN
Bên cạnh đó, với cả hai thí nghiệm được công bố ở trên, CPU đã ở mức sử dụng 100% trong các bài kiểm tra thông lượng của OpenVPN và IPSec, trong khi mức tiêu thụ CPU của WireGuard thấp hơn so với IPSEC và OpenVPN.
Thực nghiệm tốc độ truyền dữ liệu giữa WireGuard và OpenVPN
Để kiểm nghiệm hiệu quả thực tế khi triển khai sử dụng giao thức WireGuard so với một số các giao thức khác, nhóm tác giả đã tiến hành triển khai thử nghiệm theo kịch bản như sau:
- Triển khai mô hình VPN site-to-site sử dụng WireGuard.
- Cũng trên hệ thống các thiết bị đã dùng để triển khai WireGuard, tiến hành gỡ bỏ WireGuard và triển khai OpenVPN theo mô hình site-to-site.
- WireGuard có mã nguồn mở với số lượng dòng mã ít hơn các giao thức trước đó như OpenVPN hay IPSec, điều này có thể sẽ ít lỗi và giúp việc kiểm tra bảo mật thực hiện dễ dàng hơn.
- Mặc dù là một giao thức mới, WireGuard đã được nhiều nhà cung cấp dịch vụ VPN tích hợp vào trong sản phẩm và dịch vụ của họ. - WireGuard khá dễ thiết lập cả trên Linux và trên các nền tảng khác (Windows, MacOS, iOS, Android).
- Khi được thực thi trong môi trường thực nghiệm và các tài liệu được công bố, WireGuard đã được chứng minh có sự cải tiến về hiệu suất (tốc độ truyền dữ liệu), cũng như giảm mức tiêu thụ pin.
Nhược điểm của WireGuard
- Để tăng tốc độ, trong triển khai WireGuard chỉ hoạt động trên UDP, vì vậy không thể sử dụng trực tiếp đối với một số dịch vụ chỉ sử dụng TCP.
- Cơ chế bắt tay có sử dụng khóa công khai tĩnh của WireGuard, điều này có thể ảnh hưởng đến quyền riêng tư của những người dùng muốn ẩn danh.
|
TÀI LIỆU THAM KHẢO 1. Nguyễn Văn Nghị, Lê Thị Bích Hằng, Vũ Bá Linh, Hệ mã dòng có xác thực ChaCha20 - Poly1305. 2. Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, Tal Malkin, Public Key Cryptography –PKC 2006, 9th International Conference on Theory and Practice of Public-Key Cryptography New York, NY, USA, April 24-26, papes 211-232, 2026. 3. A. Langley, M. Hamburg, S. Turner, RFC 7748- Elliptic Curves for Security, Internet Research Task Force, 1/2016. 4. Hugo Krawczyk, Cryptographic Extraction and Key Derivation: The HKDF Scheme, Watson Research Center, Hawthorne, New York. Email: hugo@ee.technion.ac.il, papes15-18, 2010. 5. M-J. Saarinen, J-P. Aumasson, RFC 7693-The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC), 11/2015. 6. Jian Guo, Pierre Karpman, Ivica Nikoli, Lei Wang1, Shuang Wu, Analysis of BLAKE2, Nanyang Technological University, Singapore, 2014. 7. Peter Wu, Analysis of the WireGuard protocol, Eindhoven University of Technology, 2019. 8. Jean-Philippe Aumasson, Daniel J. Bernstein, SipHash: a fast short-input PRF, University of Illinois at Chicago, 2012. 9. Jason A. Donenfeld, WireGuard: Next Generation Kernel Network Tunnel, www.wireguard.com, 2020. 10. Jason A. Donenfeld and Kevin Milner. Formal verification of the WireGuard protocol. Technical report, July 2017. |
ThS. Đinh Văn Hùng, KS. Lê Thị Bích Hằng
