Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và phát triển hạ tầng mạng doanh nghiệp, an toàn thông tin nội bộ (Intranet/LAN) đóng vai trò sống còn đối với các tổ chức tài chính, viễn thông, cơ quan chính phủ và doanh nghiệp công nghệ. Theo các báo cáo an ninh mạng toàn cầu, hơn 60% các sự cố rò rỉ dữ liệu nghiêm trọng bắt nguồn từ các cuộc tấn công bên trong mạng nội bộ hoặc kỹ thuật nghe lén gói tin (Packet Sniffing) và giả mạo phiên (Man-in-the-Middle - MITM) khi hệ thống truyền tải dữ liệu ở dạng văn bản thuần (Plaintext) hoặc sử dụng các giao thức mã hóa đã lỗi thời.

Vấn đề cốt lõi đặt ra là phần lớn các giải pháp truyền thông tin truyền thống dựa trên giao thức tầng giao vận (Transport Layer) như TCP Socket thuần hoặc SSL 3.0/TLS 1.0/TLS 1.1/TLS 1.2 có cấu hình yếu đều chứa đựng nhiều lỗ hổng bảo mật nguy hiểm (như POODLE, BEAST, Lucky 13, DROWN). Hơn nữa, quá trình bắt tay (Handshake) của TLS 1.2 yêu cầu tới 2 vòng thời gian truyền tín hiệu (2-RTT - Round Trip Time), gây ra độ trễ (Latency) đáng kể và tiêu tốn tài nguyên tính toán đối với các kênh truyền tần suất cao.

Đồ án tốt nghiệp đại học chuyên ngành Công nghệ Thông tin tại Học viện Công nghệ Bưu chính Viễn thông với đề tài "Nghiên cứu, xây dựng giải pháp truyền tin có bảo mật mạng nội bộ với TLS 1.3" (Thực hiện: Nguyễn Quốc Bảo; Giảng viên hướng dẫn: TS. Nguyễn Mạnh Quân) đã giải quyết triệt để bài toán này bằng cách nghiên cứu toàn diện và hiện thực hóa chuẩn giao thức bảo mật tầng giao vận thế hệ mới nhất - TLS 1.3 (RFC 8446) trên nền tảng mạng LAN.

Mục tiêu cụ thể của dự án bao gồm:

  1. Nghiên cứu chuyên sâu nguyên lý hoạt động, cấu trúc phân tầng (Handshake, Record, Alert Protocol) và các cơ chế quản lý khóa theo tiêu chuẩn TLS 1.3.
  2. Thiết kế và cài đặt hệ thống truyền tin bảo mật điểm - điểm (P2P / Client-Server) hoạt động trên nền tảng Linux Socket API bằng ngôn ngữ C, tích hợp thư viện mật mã hiệu năng cao BoringSSL.
  3. Hiện thực hóa các thuật toán mã hóa xác thực dữ liệu liên kết (AEAD) tiên tiến: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305 kết hợp giao thức thỏa thuận khóa Diffie-Hellman trên đường cong Elliptic X25519.
  4. Đánh giá tính toàn vẹn, chống tấn công phát lại (Replay Attacks) và kiểm chứng hiệu năng, mức độ bảo vệ dữ liệu thông qua công cụ phân tích luồng mạng Wireshark.

Giải pháp đạt được mục tiêu giảm 50% thời gian thiết lập kết nối (chuyển từ 2-RTT xuống 1-RTT), hỗ trợ chế độ tái kết nối nhanh 0-RTT, loại bỏ hoàn toàn các thuật toán mã hóa yếu kém, đồng thời hỗ trợ truyền tệp tin và tin nhắn an toàn với kích thước phân mảnh tối đa $2^{14}$ bytes (16 KB) cho mỗi bản ghi TLS. Phạm vi ứng dụng của đề tài tập trung vào môi trường mạng LAN Linux, đóng vai trò nền tảng cho việc tích hợp vào các hệ thống truyền dẫn nhạy cảm.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi chuẩn TLS 1.3 được chuẩn hóa, các giải pháp truyền thông tin trong mạng nội bộ thường đối mặt với sự đánh đổi giữa hiệu năng và độ an toàn:

Tiêu chí TCP Socket thuần TLS 1.2 (RFC 5246) TLS 1.3 (RFC 8446) - Giải pháp đề tài
Tính bảo mật Không mã hóa (Plaintext), dễ bị nghe lén Trung bình (Dễ bị tấn công nếu cấu hình sai CBC mode) Rất cao (Bắt buộc dùng AEAD, Perfect Forward Secrecy)
Độ trễ bắt tay 0-RTT (Chỉ có TCP 3-way handshake) 2-RTT (2 vòng truyền nhận để bắt tay TLS) 1-RTT (Bắt tay thông thường) / 0-RTT (Resumption)
Bộ thuật toán (Cipher Suites) Không hỗ trợ Phức tạp, hỗ trợ nhiều thuật toán yếu (RC4, DES, 3DES, MD5) Tối giản, chỉ hỗ trợ 5 bộ AEAD an toàn tuyệt đối
Trao đổi khóa Không có RSA static, DHE, ECDHE Bắt buộc ECDHE (X25519, secp256r1) hoặc DHE
Chống tấn công phát lại Không có Phụ thuộc vào giao thức tầng ứng dụng Tích hợp sẵn thông qua Nonce, Time-stamp và Single-use Ticket

Phân tích yêu cầu hệ thống theo mô hình MoSCoW:

  • Must Have: Thiết lập kết nối Client/Server trên cổng TCP 8400; thực hiện bắt tay 1-RTT TLS 1.3; sinh khóa ngẫu nhiên và trao đổi khóa qua X25519; mã hóa luồng dữ liệu bằng AES-GCM / ChaCha20-Poly1305; xử lý cảnh báo ngắt kết nối an toàn với Alert Protocol.
  • Should Have: Quản lý dẫn xuất khóa phân tầng qua hàm HKDF; hỗ trợ truyền nhận tập tin nhị phân dung lượng linh hoạt; cơ chế đệm dữ liệu (Record Padding) để ẩn kích thước thật của gói tin.
  • Could Have: Chế độ 0-RTT Early Data với Pre-Shared Key (PSK) cho các phiên tái kết nối; cơ chế chống tấn công phát lại bằng vé đăng nhập một lần (Single-Use Tickets).
  • Won't Have: Hỗ trợ tương thích ngược với các thuật toán mật mã không an toàn (MD5, SHA-1, RC4, RSA Key Transport).

Thiết kế hệ thống

Kiến trúc giải pháp được thiết kế thành 4 mô-đun chức năng phân tầng rõ rệt, tương thích với mô hình TCP/IP:

+--------------------------------------------------------------------+
|               TẦNG ỨNG DỤNG (Application Layer)                   |
|       - Truyền tin nhắn tức thời      - Truyền nhận tập tin        |
+--------------------------------------------------------------------+
                                  |
+--------------------------------------------------------------------+
|                     TLS 1.3 PROTOCOL ENGINE                        |
|  +---------------------+  +-----------------+  +----------------+  |
|  | Handshake Protocol  |  | Alert Protocol  |  | Record Protocol|  |
|  | (X25519, HKDF-SHA)  |  | (Close, Error)  |  | (AEAD Framing) |  |
|  +---------------------+  +-----------------+  +----------------+  |
+--------------------------------------------------------------------+
                                  |
+--------------------------------------------------------------------+
|              TẦNG GIAO VẬN (Transport Layer - TCP Socket)          |
|      - Linux POSIX Sockets (socket, bind, listen, connect)        |
+--------------------------------------------------------------------+

Technology Stack & Thư viện kỹ thuật:

  • Ngôn ngữ phát triển: C (Chuẩn C99/POSIX).
  • Thư viện mật mã lõi: BoringSSL (Google Cryptographic Library - phiên bản tối ưu hóa hiệu năng và bảo mật từ OpenSSL).
  • Giao diện mạng: Linux Berkeley Sockets (BSD Sockets).
  • Môi trường triển khai: Hệ điều hành Linux (Ubuntu / Debian x86_64).
  • Công cụ kiểm thử & phân tích gói tin: Wireshark v3.x+, OpenSSL s_client CLI.

Thiết kế giao thức bắt tay và định dạng bản ghi:

  • Handshake Protocol: Quá trình đàm phán tham số diễn ra ngay trong thông điệp ClientHello (chứa các extension supported_versions=0x0304, key_share chứa khóa công khai X25519, danh sách cipher_suites) và ServerHello (chọn thuật toán, trả về khóa công khai X25519 của Server).
  • Record Protocol: Phân mảnh luồng dữ liệu ứng dụng thành các khối $TLSPlaintext \le 2^{14}$ bytes (16.384 bytes). Sau đó thực hiện mã hóa AEAD tạo thành $TLSCiphertext$ bao gồm: Content Type, Protocol Version, Length, Encrypted Payload, và 16-byte Authentication Tag.

Methodology

Dự án áp dụng phương pháp nghiên cứu và phát triển theo mô hình V-Model kết hợp quy trình phát triển an toàn (Security Development Lifecycle):

  1. Giai đoạn 1 (Nghiên cứu lý thuyết & Tiêu chuẩn): Khảo sát tài liệu RFC 8446, RFC 7539 (ChaCha20-Poly1305), RFC 7748 (Curve25519/X25519).
  2. Giai đoạn 2 (Thiết kế kiến trúc & Thuật toán): Xây dựng sơ đồ phân rã chức năng, lược đồ tuần tự bắt tay (Sequence Diagram), sơ đồ khối xử lý bản ghi.
  3. Giai đoạn 3 (Hiện thực hóa mã nguồn): Viết mã mô-đun Socket mạng, tích hợp các API BoringSSL để quản lý vòng đời TLS.
  4. Giai đoạn 4 (Kiểm thử & Thẩm định): Thiết lập mạng thử nghiệm LAN Client-Server, sử dụng Wireshark chụp gói tin kiểm chứng mã hóa, đo lường độ trễ và thông lượng.

Quản trị rủi ro tập trung vào việc ngăn chặn rò rỉ khóa trong bộ nhớ RAM (xóa sạch biến nhạy cảm bằng OPENSSL_cleanse) và chống tràn bộ đệm (Buffer Overflow) trong xử lý chuỗi và mảng nhị phân trong C.

Implementation và kết quả

Development process

Quá trình phát triển tập trung vào việc hiện thực hóa các giải thuật mật mã tiên tiến nhất được TLS 1.3 quy định.

1. Giao thức trao đổi khóa X25519 trên đường cong Montgomery

Giao thức X25519 sử dụng đường cong Elliptic Curve25519 với phương trình: $$y^2 = x^3 + 486662x^2 + x \pmod{2^{255} - 19}$$

Phép nhân vô hướng được thực hiện thông qua thuật toán Montgomery Ladder, giúp bảo vệ hệ thống trước các cuộc tấn công kênh kề (Side-channel attacks) dựa trên đo lường thời gian thực thi (Constant-time execution):

Thuật toán Montgomery Ladder tính toán k * P:
1. R0 = 0 (Điểm vô cực), R1 = P (Khóa công khai)
2. Duyệt từng bit của số nguyên bí mật k từ bit cao nhất đến bit thấp nhất:
   - Nếu bit == 0:
       R1 = LADDERSTEP_ADD(R0, R1)
       R0 = LADDERSTEP_DOUBLE(R0)
   - Nếu bit == 1:
       R0 = LADDERSTEP_ADD(R0, R1)
       R1 = LADDERSTEP_DOUBLE(R1)
3. Kết quả tọa độ x của R0 chính là khóa công khai / khóa chia sẻ bí mật.

2. Kiến trúc mã hóa dòng kết hợp xác thực ChaCha20-Poly1305

Thuật toán ChaCha20 tạo dòng khóa (Keystream) thông qua ma trận trạng thái $4 \times 4$ word (64 bytes) gồm hằng số cố định, khóa 256-bit, bộ đếm 32-bit và Nonce 96-bit. Phép biến đổi QUARTERROUND thực hiện luân phiên qua 20 vòng (10 vòng cột, 10 vòng chéo) với các phép tính cộng, XOR và dịch vòng:

#define ROTL(a,b) (((a) << (b)) | ((a) >> (32 - (b))))
#define QR(a, b, c, d) ( \
    a += b, d ^= a, d = ROTL(d, 16), \
    c += d, b ^= c, b = ROTL(b, 12), \
    a += b, d ^= a, d = ROTL(d,  8), \
    c += d, b ^= c, b = ROTL(b,  7)  \
)

Dữ liệu mã hóa sau đó được đưa qua thuật toán Poly1305 tính toán thẻ xác thực 128-bit trên trường số nguyên tố $2^{130} - 5$ để bảo đảm tính toàn vẹn.

3. Mô-đun thiết lập kết nối Socket và TLS 1.3 Context

Dưới đây là đoạn mã nguồn hiện thực phía Server khởi tạo kết nối TCP và thiết lập ngữ cảnh TLS 1.3 sử dụng thư viện BoringSSL:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <openssl/ssl.h>
#include <openssl/err.h>

#define SERVER_PORT 8400
#define BUFFER_SIZE 16384

int main() {
    SSL_CTX *ctx;
    SSL *ssl;
    int server_fd, client_fd;
    struct sockaddr_in server_addr, client_addr;
    socklen_t client_len = sizeof(client_addr);

    // 1. Khởi tạo TLS Context và cấu hình TLS 1.3
    SSL_library_init();
    ctx = SSL_CTX_new(TLS_server_method());
    if (!ctx) {
        perror("Không thể khởi tạo SSL_CTX");
        exit(EXIT_FAILURE);
    }
    // Chỉ kích hoạt giao thức TLS 1.3
    SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);
    SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION);

    // Nạp chứng chỉ số và khóa riêng của Server
    if (SSL_CTX_use_certificate_file(ctx, "server.crt", SSL_FILETYPE_PEM) <= 0 ||
        SSL_CTX_use_PrivateKey_file(ctx, "server.key", SSL_FILETYPE_PEM) <= 0) {
        ERR_print_errors_fp(stderr);
        exit(EXIT_FAILURE);
    }

    // 2. Tạo Socket TCP
    server_fd = socket(AF_INET, SOCK_STREAM, 0);
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = INADDR_ANY;
    server_addr.sin_port = htons(SERVER_PORT);

    bind(server_fd, (struct sockaddr*)&server_addr, sizeof(server_addr));
    listen(server_fd, 5);
    printf("[+] Server đang lắng nghe trên cổng TCP %d (TLS 1.3)...\n", SERVER_PORT);

    client_fd = accept(server_fd, (struct sockaddr*)&client_addr, &client_len);
    printf("[+] Kết nối TCP được chấp thuận từ Client.\n");

    // 3. Khởi tạo phiên TLS và bắt tay Handshake
    ssl = SSL_new(ctx);
    SSL_set_fd(ssl, client_fd);

    if (SSL_accept(ssl) <= 0) {
        ERR_print_errors_fp(stderr);
    } else {
        printf("[+] Bắt tay TLS 1.3 thành công! Cipher Suite: %s\n", SSL_get_cipher(ssl));
        
        char buffer[BUFFER_SIZE];
        int bytes_read = SSL_read(ssl, buffer, sizeof(buffer) - 1);
        if (bytes_read > 0) {
            buffer[bytes_read] = '\0';
            printf("[+] Dữ liệu nhận an toàn: %s\n", buffer);
            SSL_write(ssl, "Server ACK: Da nhan thong diep an toan", 38);
        }
    }

    // 4. Giải phóng tài nguyên
    SSL_shutdown(ssl);
    SSL_free(ssl);
    close(client_fd);
    close(server_fd);
    SSL_CTX_free(ctx);
    return 0;
}

Testing và validation

Hệ thống được thử nghiệm thực tế trong mạng LAN giữa 2 máy trạm chạy hệ điều hành Ubuntu Linux, kết nối qua Switch mạng nội bộ tại địa chỉ IP Server 192.168.1.50 và Client 192.168.1.51.

  1. Kiểm thử Bắt tay Handshake: Client gửi thông điệp ClientHello chứa khóa công khai X25519 (32 bytes) và 3 bộ thuật toán AEAD được hỗ trợ:

    • TLS_AES_128_GCM_SHA256 (0x1301)
    • TLS_AES_256_GCM_SHA384 (0x1302)
    • TLS_CHACHA20_POLY1305_SHA256 (0x1303) Server tự động chọn TLS_CHACHA20_POLY1305_SHA256, tính toán khóa bí mật dùng chung (Shared Secret), phản hồi ServerHello kèm khóa công khai Server và chứng thư số. Quá trình bắt tay hoàn tất chỉ trong đúng 1-RTT.

  2. Kiểm thử Truyền Tệp tin (ThanhBien_K26.txt): Client thực hiện lệnh list_file để duyệt danh mục tệp tin chia sẻ tại Server và gửi yêu cầu sao chép tệp tin. Dữ liệu tệp được phân mảnh thành các khối 16 KB, mã hóa AEAD và truyền qua kênh an toàn. File nhận tại Client trùng khớp 100% mã checksum SHA-256 so với file gốc trên Server.

  3. Phân tích luồng gói tin bằng Wireshark:

    • Bắt gói tin trên giao diện mạng eth0 / wlan0.
    • Gói tin số 1 (ClientHello): Thấy rõ extension supported_versions chứa TLS 1.3 (0x0304) và extension key_share.
    • Gói tin số 2 (ServerHello): Chứa khóa công khai Server. Toàn bộ các thông điệp tiếp theo như EncryptedExtensions, Certificate, CertificateVerify, Finished và Application Data đều được mã hóa hoàn toàn.
    • Nội dung bản rõ của tin nhắn chat và tệp tin văn bản bị xáo trộn thành chuỗi nhị phân ngẫu nhiên, không thể trích xuất nếu không có khóa phiên (Session Key).
Wireshark Packet Trace Breakdown:
No.  Source          Destination     Protocol  Info
1    192.168.1.51    192.168.1.50    TCP       8400 -> 8400 [SYN]
2    192.168.1.50    192.168.1.51    TCP       8400 -> 8400 [SYN, ACK]
3    192.168.1.51    192.168.1.50    TCP       8400 -> 8400 [ACK]
4    192.168.1.51    192.168.1.50    TLSv1.3   Client Hello (X25519 Key Share)
5    192.168.1.50    192.168.1.51    TLSv1.3   Server Hello, Change Cipher Spec, Encrypted Extensions
6    192.168.1.50    192.168.1.51    TLSv1.3   Certificate, Certificate Verify, Finished
7    192.168.1.51    192.168.1.50    TLSv1.3   Finished
8    192.168.1.51    192.168.1.50    TLSv1.3   Application Data (Mã hóa ChaCha20-Poly1305)

Kết quả đạt được

  • Hoàn thành 100% mục tiêu chức năng: Xây dựng thành công ứng dụng truyền tin P2P / Client-Server hỗ trợ gửi tin nhắn trực tiếp và sao chép tệp tin an toàn trong mạng nội bộ.
  • Tối ưu hóa hiệu năng vượt trội: Độ trễ thiết lập kết nối giảm từ ~18.4ms (đo trên TLS 1.2 trong mạng LAN thử nghiệm) xuống còn ~9.2ms với TLS 1.3 (giảm xấp xỉ 50% độ trễ mạng).
  • Tính toàn vẹn tuyệt đối: 100% các phân mảnh dữ liệu bị sửa đổi (Bit-flip attack thử nghiệm) đều bị tầng Record Protocol từ chối tiếp nhận và ngắt kết nối với cảnh báo Alert bad_record_mac.

Đổi mới và đóng góp

  1. Loại bỏ triệt để các lỗ hổng mã hóa cổ điển: Khác với các hệ thống truyền tin nội bộ vẫn còn duy trì chuẩn TLS 1.2 với các bộ mã hóa CBC (dễ bị tấn công Padding Oracle), giải pháp trong đồ án bắt buộc 100% các luồng truyền thông phải sử dụng chuẩn mã hóa xác thực AEAD (AES-GCM hoặc ChaCha20-Poly1305). Điều này loại bỏ hoàn toàn khả năng can thiệp hay sửa đổi dữ liệu từ kẻ tấn công trung gian.

  2. Cải tiến tốc độ xử lý nhờ đường cong Elliptic X25519: Thay vì sử dụng các đường cong NIST (secp256r1) có tốc độ tính toán chậm hơn và tiềm ẩn nghi vấn về tham số backdoor, đồ án đã triển khai thuật toán X25519 với phép toán Montgomery Ladder tối ưu, mang lại tốc độ sinh khóa và tính toán khóa bí mật nhanh hơn 2.5 lần so với RSA-2048 truyền thống.

  3. Cơ chế quản lý khóa phân cấp HKDF vững chắc: Toàn bộ khóa phiên (Traffic Keys) và khóa dẫn xuất được quản lý nghiêm ngặt theo mô hình HKDF (HMAC-based Key Derivation Function), đảm bảo tính bảo mật chuyển tiếp hoàn hảo (Perfect Forward Secrecy - PFS). Nếu một khóa phiên của một tệp tin bị lộ, toàn bộ các phiên truyền tin trước và sau đó vẫn an toàn tuyệt đối.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng (Use Cases)

  • Truyền dẫn dữ liệu y tế & hồ sơ bệnh án trong mạng LAN bệnh viện: Bảo vệ dữ liệu nhạy cảm của bệnh nhân không bị nghe lén bởi các thiết bị lạ kết nối vào mạng Wi-Fi nội bộ.
  • Kênh đồng bộ dữ liệu giao dịch nội bộ ngành ngân hàng: Kết nối an toàn giữa các máy chủ chi nhánh và máy chủ trung tâm trong mạng Core Banking.
  • Hệ thống điều khiển công nghiệp (SCADA / ICS): Mã hóa các lệnh điều khiển gửi tới PLC và cảm biến mạng nội bộ với độ trễ tối thiểu (1-RTT).

Yêu cầu triển khai và cấu hình hệ thống

  • Hệ điều hành: Linux Kernel 4.15 trở lên (hỗ trợ đầy đủ socket non-blocking và epoll nếu cần mở rộng).
  • Cấu hình phần cứng tối thiểu: CPU 1.0 GHz (hỗ trợ tập lệnh phần cứng AES-NI là lợi thế lớn), RAM 512 MB, Card mạng 100/1000 Mbps.
  • Môi trường phụ thuộc: libssl-dev, libcrypto-dev hoặc mã nguồn biên dịch tĩnh từ BoringSSL.
# Hướng dẫn biên dịch và khởi chạy chương trình
# 1. Biên dịch mã nguồn Server và Client với BoringSSL
gcc -o tls_server server.c -lssl -lcrypto
gcc -o tls_client client.c -lssl -lcrypto

# 2. Tạo chứng chỉ số tự ký (Self-signed Certificate) cho mạng LAN
openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes -subj "/CN=LAN_Secure_Server"

# 3. Khởi chạy Server trên máy chủ
./tls_server

# 4. Khởi chạy Client kết nối và truyền tệp tin
./tls_client 192.168.1.50 8400

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  1. Giao diện người dùng: Hệ thống hiện hoạt động hoàn toàn trên giao diện dòng lệnh (CLI), chưa xây dựng giao diện đồ họa trực quan (GUI) cho người dùng phổ thông.
  2. Cơ chế xác thực chứng chỉ động: Đang sử dụng chứng chỉ tự ký (Self-signed Certificate) nội bộ được cấu hình tĩnh tại máy trạm, chưa tích hợp máy chủ thẩm quyền chứng thực CA doanh nghiệp hoặc giao thức ACME tự động.
  3. Mô hình kết nối đồng thời: Chương trình thực nghiệm hiện phục vụ kết nối tuần tự hoặc đa luồng cơ bản (POSIX threads), chưa tối ưu hóa với mô hình hướng sự kiện I/O Multiplexing (như epoll / io_uring) để đáp ứng hàng trăm nghìn kết nối đồng thời.

Hướng phát triển

  • Tích hợp giao thức QUIC (HTTP/3) chạy trên nền UDP kết hợp với TLS 1.3 để giảm thiểu hoàn toàn hiện tượng nghẽn dòng (Head-of-line blocking).
  • Phát triển module giao diện đồ họa đa nền tảng bằng Electron hoặc Flutter cho các ứng dụng chat/truyền file bảo mật doanh nghiệp.
  • Mở rộng hỗ trợ các thuật toán mật mã hậu lượng tử (Post-Quantum Cryptography - PQC) như Kyber / Dilithium trong pha đàm phán bắt tay TLS 1.3.

Đối tượng hưởng lợi

  • Sinh viên & Học viên Cao học ngành CNTT / ATTT: Có nguồn tài liệu tham khảo chi tiết, chuẩn mực về cách phân tầng giao thức TLS 1.3 và kỹ thuật lập trình Socket C nâng cao.
  • Kỹ sư An toàn Thông tin & Lập trình viên Hệ thống: Tiếp cận mẫu thiết kế (Design Pattern) và mã nguồn thực thi giao thức bắt tay TLS 1.3 trên nền thư viện BoringSSL hiệu năng cao.
  • Doanh nghiệp vừa và nhỏ (SMEs): Sở hữu giải pháp mẫu miễn phí, mã nguồn mở để thiết lập kênh truyền tin nội bộ an toàn mà không cần đầu tư các thiết bị phần cứng tường lửa đắt đỏ.
  • Các nhà nghiên cứu Mật mã học: Nền tảng thực nghiệm để tiếp tục đánh giá hiệu năng các bộ thuật toán mã hóa nhẹ (Lightweight Cryptography) trên thiết bị nhúng IoT.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai giải pháp này là gì?

Giải pháp yêu cầu hệ điều hành Linux (Ubuntu, Debian, CentOS) có trình biên dịch GCC phiên bản 7.0 trở lên, cài đặt thư viện BoringSSL hoặc OpenSSL phiên bản 1.1.1+ (phiên bản đầu tiên hỗ trợ đầy đủ TLS 1.3 theo RFC 8446). Máy chủ và máy trạm cần thông suốt cổng TCP 8400 trong tường lửa nội bộ.

2. Cơ chế 0-RTT trong TLS 1.3 có nguy cơ bị tấn công phát lại (Replay Attack) không và xử lý thế nào?

Có. Dữ liệu gửi trong gói tin 0-RTT (Early Data) không được bảo vệ bằng tham số ngẫu nhiên của phiên hiện tại, nên kẻ tấn công có thể bắt gói tin và gửi lại cho Server. Đồ án xử lý rủi ro này bằng cách chỉ cho phép sử dụng vé đăng nhập một lần (Single-Use Tickets) và gắn nhãn tem thời gian (Timestamp) nghiêm ngặt để Server tự động từ chối các gói tin nằm ngoài khung thời gian cho phép.

3. Làm thế nào để tích hợp module TLS 1.3 này vào một ứng dụng Socket TCP sẵn có?

Lập trình viên chỉ cần giữ nguyên cấu trúc Socket TCP (socket, bind, connect) và bọc luồng I/O bằng các hàm của BoringSSL/OpenSSL: thay thế read() / write() bằng SSL_read() / SSL_write(), đồng thời khởi tạo SSL_CTX với cờ TLS_method() và giới hạn phiên bản SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION).

4. Tại sao đồ án lại lựa chọn thuật toán ChaCha20-Poly1305 bên cạnh AES-GCM?

Mặc dù AES-GCM rất nhanh trên các CPU hiện đại có hỗ trợ tập lệnh tăng tốc phần cứng AES-NI, nhưng trên các thiết bị nhúng hoặc CPU cũ không có AES-NI, AES sẽ chạy chậm và dễ bị tấn công kênh kề dựa trên bộ nhớ đệm (Cache-timing attacks). ChaCha20-Poly1305 được thiết kế hoàn toàn dựa trên các phép toán số học 32-bit cơ bản, đảm bảo tốc độ cực cao và an toàn tuyệt đối trên mọi nền tảng phần cứng.

5. Chi phí triển khai giải pháp và khả năng tiết kiệm ngân sách ra sao?

Giải pháp được xây dựng hoàn toàn từ các công nghệ mã nguồn mở (C, Linux, BoringSSL) nên chi phí bản quyền phần mềm là 0 đồng. Việc nâng cấp lên TLS 1.3 giúp doanh nghiệp ngăn ngừa các vụ lộ lọt bí mật kinh doanh có thể gây thiệt hại hàng tỷ đồng, đồng thời tối ưu hóa 50% thời gian trễ mạng mà không cần nâng cấp phần cứng mạng đắt đỏ.

Kết luận

Đồ án tốt nghiệp "Nghiên cứu, xây dựng giải pháp truyền tin có bảo mật mạng nội bộ với TLS 1.3" đã giải quyết xuất sắc bài toán bảo mật dữ liệu tầng giao vận trong mạng LAN. Thông qua việc phân tích chuyên sâu lý thuyết mật mã học hiện đại, đồ án đã hiện thực hóa thành công một hệ thống truyền tin Socket C hoàn chỉnh, tích hợp chuẩn TLS 1.3 với các thuật toán tối tân (X25519, ChaCha20-Poly1305, AES-GCM, HKDF).

Kết quả thử nghiệm thực tế chứng minh giải pháp không chỉ bảo vệ tuyệt đối tính bí mật và toàn vẹn của dữ liệu trước các cuộc tấn công nghe lén, giả mạo và phát lại gói tin, mà còn tối ưu hóa vượt bậc về mặt hiệu năng (giảm 50% độ trễ bắt tay mạng). Đây là tiền đề kỹ thuật vững chắc để tiếp tục mở rộng, đóng gói thành các thư viện bảo mật và giải pháp truyền thông tin cậy trong các hạ tầng mạng doanh nghiệp quy mô lớn.