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).
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.
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 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 (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].
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 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].
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.
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].
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.
Để 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.
- Để 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
10:00 | 27/05/2022
10:00 | 25/04/2023
15:00 | 13/04/2022
15:00 | 19/02/2024
14:00 | 13/05/2021
08:00 | 08/08/2024
Trí tuệ nhân tạo (AI) có khả năng xác định và ưu tiên các rủi ro, mang lại cho các chuyên gia IT cơ hội phát hiện ngay lập tức mã độc trong mạng của họ và phát triển chiến lược phản ứng sự cố. Hiện nay, AI đóng vai trò quan trọng trong quản lý an toàn thông tin (ATTT), đặc biệt là trong việc phản ứng với sự cố, dự đoán việc xâm phạm, kiểm soát hiệu suất và quản lý hàng tồn kho. Bài viết này giới thiệu về các ứng dụng của AI trong quản lý ATTT bằng cách xem xét những lợi ích và thách thức của nó, đồng thời đề xuất các lĩnh vực cho các nghiên cứu trong tương lai.
08:00 | 07/05/2024
Sự phổ biến của các giải pháp truyền tệp an toàn là minh chứng cho nhu cầu của các tổ chức trong việc bảo vệ dữ liệu của họ tránh bị truy cập trái phép. Các giải pháp truyền tệp an toàn cho phép các tổ chức bảo vệ tính toàn vẹn, bí mật và sẵn sàng cho dữ liệu khi truyền tệp, cả nội bộ và bên ngoài với khách hàng và đối tác. Các giải pháp truyền tệp an toàn cũng có thể được sử dụng cùng với các biện pháp bảo mật khác như tường lửa, hệ thống phát hiện xâm nhập (IDS), phần mềm chống virus và công nghệ mã hóa như mạng riêng ảo (VPN). Bài báo sẽ thông tin tới độc giả những xu hướng mới nổi về chia sẻ tệp an toàn năm 2024, từ các công nghệ, giải pháp nhằm nâng cao khả năng bảo vệ dữ liệu trước các mối đe dọa tiềm ẩn.
08:00 | 12/03/2024
Lộ thông tin thẻ tín dụng gây ra nhiều hệ lụy nghiêm trọng, nguy cơ mất tiền là rất cao. Bài báo giới thiệu một số cách thức giúp người dùng giảm nguy cơ khi phát hiện thông tin thẻ tín dụng bị lộ.
09:00 | 13/02/2024
Trong bối cảnh an ninh mạng ngày càng phát triển, các tổ chức liên tục phải đấu tranh với một loạt mối đe dọa trên môi trường mạng ngày càng phức tạp. Các phương pháp an toàn, an ninh mạng truyền thống thường sử dụng các biện pháp bảo vệ thống nhất trên các hệ thống đang tỏ ra kém hiệu quả trước các hình thái tấn công ngày càng đa dạng. Điều này đặt ra một bài toán cần có sự thay đổi mô hình bảo vệ theo hướng chiến lược, phù hợp và hiệu quả hơn thông qua việc Quản lý rủi ro bề mặt tấn công (Attack Surface Risk Management - ASRM).
08:00 | 11/01/2024 | Chính sách - Chiến lược
09:00 | 10/01/2024 | Giải pháp khác
09:00 | 05/01/2024|Chính sách - Chiến lược
09:00 | 05/01/2024|An ninh – Quốc Phòng
Trong thời đại ngày nay, cùng với sự phát triển của khoa học kỹ thuật có ngày càng nhiều những cuộc tấn công vào phần cứng và gây ra nhiều hậu quả nghiêm trọng. So với các loại tấn công khác, tấn công qua kênh kề đang được nghiên cứu do khả năng khôi phục lại khóa bí mật trong khi hệ thống vẫn hoạt động bình thường mà không hề làm thay đổi phần cứng. Bài báo này sẽ trình bày một cách sơ lược về những kết quả cuộc tấn công kênh kề lên mã hóa RSA cài đặt trên điện thoại thông minh sử dụng hệ điều hành Android tại Viện Khoa học - Công nghệ mật mã. Nhóm tác giả đã tấn công khôi phục được một phần khóa bí mật của mã hóa RSA cài đặt trên điện thoại thông minh và chứng minh khả năng rò rỉ thông tin qua kênh kề.
14:00 | 11/09/2024
Hệ thống TETRA được sử dụng rộng rãi cho các hệ thống thông tin chuyên dùng như cảnh sát, cứu hỏa, dịch vụ khẩn cấp, dịch vụ an ninh thậm chí là quân đội [1]. Tuy nhiên với sự phát triển của công nghệ di động mạng tổ ong công cộng (GSM, 3G, 4G, 5G), nhiều ý kiến cho rằng nhiều người dùng TETRA có thể sẽ chuyển sang sử dụng hệ thống công cộng. Bài báo này phân tích những yêu cầu chặt chẽ của TETRA và những ưu điểm nó với hệ thống truyền thông công cộng, từ đó có cái nhìn tổng thể hơn về xây dựng hệ thống liên lạc chuyên dùng với TETRA.
09:00 | 17/09/2024
