Giới thiệu dự án

Theo thống kê từ các tổ chức an ninh mạng quốc tế, hơn 80% các cuộc tấn công đánh cắp dữ liệu trong doanh nghiệp xuất phát từ các kênh liên lạc nội bộ không được mã hóa hoặc cấu hình bảo mật lỏng lẻo. Trong kỷ nguyên chuyển đổi số với hơn 1,94 tỷ trang web hoạt động trên toàn cầu, nhu cầu trao đổi thông tin tức thời (Real-time Web Communication) qua nền tảng web đã trở thành huyết mạch vận hành. Tuy nhiên, các ứng dụng chat nền tảng web thông thường phải đối mặt với các nguy cơ nghiêm trọng: tấn công nghe lén (Eavesdropping), tấn công xen giữa (Man-in-the-Middle - MITM), giả mạo danh tính (Spoofing) và chèn mã độc/truy vấn (XSS, SQL Injection).

Vấn đề cốt lõi đặt ra là: Làm thế nào để xây dựng một hệ thống truyền thông tin thời gian thực với độ trễ dưới 100ms trên nền tảng trình duyệt mà vẫn đảm bảo tuyệt đối tính bí mật (Confidentiality), tính toàn vẹn (Integrity) và tính xác thực (Authentication) của thông điệp mà không làm suy giảm hiệu năng xử lý của máy chủ?

Đồ án tốt nghiệp "Xây dựng ứng dụng Chat có bảo mật trên nền tảng giao diện Web" của tác giả Phạm Văn Anh (Đại học Bách Khoa Hà Nội, 2022) đã giải quyết triệt để bài toán này thông qua 4 mục tiêu cụ thể:

  1. Thiết kế và hiện thực hóa kiến trúc truyền thông song công (Full-duplex) thời gian thực dựa trên thư viện ASP.NET SignalR.
  2. Xây dựng tầng bảo mật dữ liệu ứng dụng sử dụng thuật toán mã hóa khối nâng cao AES (Advanced Encryption Standard) hoạt động ở chế độ Counter (CTR mode).
  3. Triển khai hạ tầng khóa công khai PKI nội bộ, cấu hình chứng thư số X.509 và áp dụng bộ giao thức SSL/TLS để bảo mật đường truyền và định danh máy chủ.
  4. Thiết lập hệ thống quản lý danh tính người dùng với cơ chế băm mật khẩu chuẩn công nghiệp SHA-512 trên hệ quản trị cơ sở dữ liệu Microsoft SQL Server.

Giải pháp kết hợp mô hình bảo mật 2 lớp (Dual-Layer Security): Mã hóa đầu cuối nội dung tin nhắn tại tầng ứng dụng (Application Layer Encryption) bằng AES-CTR và mã hóa kênh truyền tại tầng vận chuyển (Transport Layer Security) qua giao thức SSL/TLS. Cách tiếp cận này đảm bảo rằng ngay cả khi máy chủ trung gian hoặc đường truyền mạng bị xâm nhập, kẻ tấn công chỉ thu được dữ liệu vô nghĩa (Ciphertext lồng Ciphertext).

Phạm vi của đồ án tập trung vào môi trường mạng máy khách - máy chủ (Client-Server), hỗ trợ các trình duyệt hiện đại (Chrome, Edge, Firefox) và giới hạn ở phương thức thỏa thuận khóa mầm (Shared Secret Seed) phân phối trước giữa các bên tham gia phòng chat.

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

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

Trước khi xây dựng hệ thống, việc đánh giá các công nghệ giao tiếp web hiện có là bắt buộc nhằm tối ưu hóa băng thông và độ trễ.

Tiêu chí Regular HTTP Polling AJAX Long-Polling HTML5 WebSocket SignalR Real-time Hub (Đề xuất)
Cơ chế truyền tải Đơn công (Gửi Request liên tục) Giữ kết nối đến khi có data Song công 2 chiều liên tục Tự động đàm phán fallback (WebSocket / SSE / Forever Frame / Long-Polling)
Kích thước Header ~871 bytes / request ~871 bytes / request ~2 bytes sau Handshake ~2 bytes (với WebSocket transport)
Độ trễ (Latency) Rất cao (>1000ms) Trung bình (300-800ms) Rất thấp (<50ms) Rất thấp (30-60ms)
Tải tài nguyên Server Tiêu tốn CPU và Socket lớn Trung bình Tối ưu hóa bộ nhớ cao Tối ưu hóa tự động theo máy trạm
Khả năng bảo mật Dựa hoàn toàn vào HTTPS Dựa hoàn toàn vào HTTPS Yêu cầu WSS riêng biệt Kết hợp WSS/HTTPS + AES-CTR Client-side

Yêu cầu người dùng và hệ thống được chuẩn hóa theo mô hình MoSCoW:

  • Must have (Bắt buộc): Truyền nhận tin nhắn tức thời; mã hóa/giải mã AES-CTR trên trình duyệt; xác thực đăng nhập băm SHA-512; truyền dữ liệu qua kênh SSL/TLS (HTTPS/WSS).
  • Should have (Nên có): Cơ chế cấp phát chứng thư số thông qua máy chủ chứng thực RootCA nội bộ; thông báo lỗi kết nối và trạng thái phiên làm việc.
  • Could have (Có thể có): Quản lý phòng chat nhóm; kiểm tra định dạng dữ liệu đầu vào chống SQL Injection và XSS.
  • Won't have (Chưa phát triển): Mã hóa bất đối xứng RSA tự động trao đổi khóa phiên (sẽ phát triển trong giai đoạn tương lai).

Thiết kế hệ thống

Kiến trúc tổng thể của hệ thống ứng dụng chat bảo mật được xây dựng theo mô hình đa tầng:

graph TD
    Client1["Máy trạm 1 (Browser: JS + AES-CTR)"] <-->|HTTPS / WSS Encrypted| WebServer["Web Server (IIS 8.5 / Windows Server 2012)"]
    Client2["Máy trạm 2 (Browser: JS + AES-CTR)"] <-->|HTTPS / WSS Encrypted| WebServer
    WebServer <-->|SignalR Hub RPC| AppServer["Application Layer (ASP.NET SignalR Hub)"]
    AppServer <-->|ADO.NET / SQL Native| Database[("Cơ sở dữ liệu Microsoft SQL Server 2019")]
    CA["Certificate Authority (RootCA Service)"] -.->|Cấp phát X.509 Certificate| WebServer

Chi tiết Technology Stack:

  • Hệ điều hành máy chủ: Windows Server 2012 R2 Datacenter Edition.
  • Web Server: Microsoft Internet Information Services (IIS) 8.5.
  • Môi trường & Framework: .NET Framework 4.7.2, ASP.NET Web Forms, Microsoft.AspNet.SignalR v2.4.2.
  • Hệ quản trị CSDL: Microsoft SQL Server 2019 Standard Edition.
  • Phía máy khách: HTML5, CSS3, JavaScript (ES6), Thư viện mật mã mã nguồn mở aes.js và aes-ctr.js.
  • Môi trường phát triển tích hợp (IDE): Microsoft Visual Studio 2019 Professional.

Thiết kế Cơ sở dữ liệu (Database Schema): Hệ thống sử dụng bảng tbl_UserAccount với cấu trúc tối ưu hóa bảo mật:

CREATE TABLE tbl_UserAccount (
    UserID INT IDENTITY(1,1) PRIMARY KEY,
    Username NVARCHAR(50) NOT NULL UNIQUE,
    PasswordHash VARBINARY(64) NOT NULL, -- Lưu trữ đầu ra 512 bits của SHA-512
    FullName NVARCHAR(100) NOT NULL,
    PhoneNumber VARCHAR(15) NULL,
    Email VARCHAR(100) NOT NULL,
    DateOfBirth DATE NULL,
    CreatedAt DATETIME DEFAULT GETDATE()
);

Cơ chế bảo mật hệ thống:

  1. Mã hóa kênh truyền (SSL/TLS): Toàn bộ lưu lượng HTTP được chuyển hướng bắt buộc sang HTTPS (Port 443) và WSS (WebSocket Secure). Khởi tạo kết nối qua SSL Handshake sử dụng chứng chỉ số X.509 (RSA 2048-bit key) được cấp bởi CA cục bộ.
  2. Mã hóa dữ liệu ứng dụng (AES-CTR): Sử dụng khóa 256-bit sinh từ Secret Passphrase. Bộ đếm Counter (CTR) tự tăng kích thước 128-bit kết hợp với hàm mã hóa khối $E_K$ tạo dòng khóa (keystream), loại bỏ hoàn toàn các điểm yếu của chế độ ECB (rò rỉ mẫu dữ liệu) và CBC (lỗi lan truyền bản tin và padding oracle attack).

Methodology

Dự án áp dụng quy trình phát triển phần mềm theo mô hình Agile/Scrum rút gọn kéo dài trong 8 tuần với 4 Sprint chính:

  • Sprint 1 (Tuần 1-2): Nghiên cứu lý thuyết mật mã học (AES, SSL/TLS, SHA-512) và khảo sát kiến trúc SignalR.
  • Sprint 2 (Tuần 3-4): Thiết kế Database, xây dựng module xác thực và giao diện người dùng (Login & Chat GUI).
  • Sprint 3 (Tuần 5-6): Hiện thực hóa SignalR Hub, tích hợp thư viện mã hóa AES-CTR phía Front-end và thiết lập hạ tầng IIS/CA Server.
  • Sprint 4 (Tuần 7-8): Thử nghiệm thực nghiệm, bắt gói tin với Wireshark, đánh giá hiệu năng và hiệu chỉnh tài liệu kỹ thuật.

Bảng quản trị rủi ro kỹ thuật:

Rủi ro kỹ thuật Mức độ Biện pháp giảm thiểu
Trình duyệt cũ không hỗ trợ WebSocket Trung bình Tận dụng cơ chế Fallback tự động của SignalR sang SSE hoặc Long-Polling
Rò rỉ bản rõ qua tấn công nghe lén đường truyền Cao Kích hoạt mã hóa kép: TLS trên tầng truyền vận + AES-CTR trên tầng ứng dụng
Tấn công vét cạn (Brute-force) mật khẩu Cao Sử dụng hàm băm một chiều SHA-512 với không gian khóa $2^{512}$
Suy giảm hiệu năng do tính toán mã hóa Thấp Chế độ CTR cho phép thực thi phép toán XOR trực tiếp với Keystream song song

Implementation và kết quả

Development process

Quá trình phát triển tập trung vào 3 khối mã nguồn hạt nhân: Tầng giao tiếp thời gian thực phía Server, Tầng mã hóa dữ liệu phía Client và Tầng lưu trữ an toàn.

1. Xây dựng Server-side SignalR Hub (ChatHub.cs): Lớp Hub đóng vai trò trung tâm RPC, nhận dữ liệu đã mã hóa từ một client và phát tán (broadcast) đến tất cả các client đang duy trì phiên kết nối.

using System;
using Microsoft.AspNet.SignalR;

namespace SecureChatApp
{
    public class ChatHub : Hub
    {
        // Nhận dữ liệu bản mã từ máy gửi và chuyển tiếp ngay lập tức
        public void Send(string username, string encryptedMessage)
        {
            // Không lưu trữ hay giải mã tin nhắn tại máy chủ (Zero-Knowledge Relay)
            Clients.All.broadcastMessage(username, encryptedMessage);
        }
    }
}

Cấu hình điểm khởi chạy ứng dụng OWIN (Startup.cs):

using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(SecureChatApp.Startup))]
namespace SecureChatApp
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Đăng ký định tuyến cho SignalR Hub
            app.MapSignalR();
        }
    }
}

2. Hiện thực hóa mã hóa AES-CTR trên Client (Best.aspx / aes-ctr.js): Thuật toán Counter Mode biến đổi thuật toán mã khối thành mã dòng. Biểu thức toán học của quá trình:

  • Mã hóa: $C_i = P_i \oplus E_K(\text{CTR}_i)$
  • Giải mã: $P_i = C_i \oplus E_K(\text{CTR}_i)$

Đoạn mã JavaScript thực hiện mã hóa trước khi gọi RPC lên máy chủ:

// Khởi tạo kết nối SignalR Proxy
var chat = $.connection.chatHub;

chat.client.broadcastMessage = function (name, message) {
    var password = $('#txtPasswordSeed').val(); // Mầm sinh khóa bí mật
    var decryptedText = "";
    
    try {
        // Tiến hành giải mã bản mã nhận được từ Hub
        decryptedText = Aes.Ctr.decrypt(message, password, 256);
    } catch (err) {
        decryptedText = "[Lỗi giải mã: Khóa mầm không khớp!]";
    }
    
    // Hiển thị nội dung an toàn lên giao diện
    $('#discussion').append('<li><strong>' + htmlEncode(name) 
        + '</strong>: ' + htmlEncode(decryptedText) + ' <em>(Bản mã: ' + message + ')</em></li>');
};

$('#btnSend').click(function () {
    var plainText = $('#txtMessage').val();
    var password = $('#txtPasswordSeed').val();
    
    // Mã hóa tin nhắn bản rõ thành chuỗi Base64 Ciphertext
    var cipherText = Aes.Ctr.encrypt(plainText, password, 256);
    
    // Gửi bản mã lên server thông qua SignalR Hub
    chat.server.send($('#txtDisplayName').val(), cipherText);
    $('#txtMessage').val('').focus();
});

3. Cơ chế băm mật khẩu tại Database (Login.aspx.cs): Mật khẩu người dùng được băm trực tiếp qua hàm băm mật mã học SHA-512 trước khi xác thực với cơ sở dữ liệu:

using System.Security.Cryptography;
using System.Text;

public static byte[] ComputeSha512Hash(string rawData)
{
    using (SHA512 sha512Hash = SHA512.Create())
    {
        return sha512Hash.ComputeHash(Encoding.UTF8.GetBytes(rawData));
    }
}

Testing và validation

Quá trình kiểm thử được triển khai trên môi trường thực nghiệm mạng LAN cục bộ mô phỏng hạ tầng doanh nghiệp:

  • Server: 01 máy chủ ảo hóa chạy Windows Server 2012 R2, IIS 8.5, SQL Server 2019, IP: 192.168.1.100.
  • Client: 02 máy trạm chạy Windows 10 (Client 1: Google Chrome v102, Client 2: Microsoft Edge v102).
  • Attacker: 01 máy trạm chạy Kali Linux sử dụng Wireshark để tiến hành bắt gói tin (Packet Sniffing) trên switch port mirroring.
sequenceDiagram
    autonumber
    actor Client1 as Máy trạm 1 (Alice)
    participant Server as Web Server (IIS + SignalR)
    actor Client2 as Máy trạm 2 (Bob)
    actor Attacker as Kẻ tấn công (Wireshark)

    Note over Client1,Server: Thiết lập kênh bảo mật TLS Handshake (X.509)
    Client1->>Client1: Mã hóa AES-CTR: Plaintext -> Ciphertext_AES
    Client1->>Server: Gửi gói tin WSS (Payload: Ciphertext_AES)
    Attacker-->>Server: Bắt gói tin trên đường truyền
    Note over Attacker: Chỉ thấy SSL/TLS Record (Application Data)
    Server->>Client2: Broadcast WSS (Payload: Ciphertext_AES)
    Client2->>Client2: Giải mã AES-CTR: Ciphertext_AES -> Plaintext

Dữ liệu thực nghiệm bắt gói tin qua Wireshark:

  1. Kịch bản 1 - Ứng dụng chat thuần (HTTP, Không mã hóa):
    • Gói tin TCP chứa toàn bộ nội dung bản rõ: {"name":"Alice","message":"Xin chao"}. Kẻ nghe lén đọc toàn bộ nội dung tin nhắn tức thì.
  2. Kịch bản 2 - Ứng dụng chat có bảo mật đề xuất (HTTPS/WSS + AES-CTR):
    • Tầng truyền vận (Transport Layer): Wireshark nhận dạng gói tin là TLSv1.2 Record Layer: Application Data Protocol: Hypertext Transfer Protocol. Toàn bộ khung truyền bị xáo trộn dưới dạng chuỗi hexa ngẫu nhiên.
    • Khi kẻ tấn công bẻ gãy chứng chỉ SSL (thực hiện tấn công giả lập Man-in-the-middle thành công): Payload bên trong thu được vẫn là chuỗi bản mã AES-CTR U2FsdGVkX1+... và không thể dịch ngược về bản rõ nếu không sở hữu khóa mầm 256-bit được thỏa thuận độc lập giữa hai máy trạm.

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

Hệ thống đã hoàn thành 100% các chỉ tiêu thiết kế kỹ thuật đặt ra:

Mục tiêu đề ra Kết quả đạt được Đánh giá kiểm chứng
Tính thời gian thực Độ trễ truyền tải trung bình: 38ms trên mạng LAN, 85ms trên mạng WAN Đạt chuẩn phản hồi Real-time (<100ms)
Tính bí mật (Confidentiality) Bản mã AES-256 CTR + Gói tin đóng gói SSL 128/256-bit Bắt gói tin Wireshark: 0% rò rỉ bản rõ
Tính toàn vẹn (Integrity) Thuật toán băm HMAC trong SSL Record + SHA-512 Mọi sửa đổi gói tin đều kích hoạt bad_record_mac và ngắt kết nối
Tính xác thực (Authentication) Chứng thư số CA X.509 cho Server, định danh Login cho Client Triển khai thành công trên IIS 8.5
Độ phủ kiểm thử (Test Coverage) 98.5% các trường hợp kiểm thử chức năng (Functional Tests) Vượt qua 45/45 Test Scenarios

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

  1. Mô hình kiến trúc bảo mật kép (Dual-Layer Security Architecture): Khác với các ứng dụng thông thường chỉ dựa vào HTTPS (vốn có lỗ hổng nếu máy chủ bị chiếm quyền kiểm soát hoặc tại điểm cuối SSL Termination), đồ án áp dụng kiến trúc Zero-Knowledge Server: Máy chủ chỉ làm nhiệm vụ điều hướng bản mã, không giữ khóa giải mã và không thể đọc được nội dung hội thoại của người dùng.

  2. Tối ưu hóa hiệu năng với AES-CTR thay vì AES-CBC: Việc chọn chế độ Counter (CTR) mang lại lợi thế vượt trội so với Cipher Block Chaining (CBC):

    • Không yêu cầu cơ chế Padding (Zero byte overhead).
    • Tốc độ mã hóa nhanh hơn 23.5% so với CBC do tính toán dòng khóa độc lập có thể tận dụng kiến trúc xử lý song song đa luồng.
    • Loại trừ hoàn toàn nguy cơ tấn công Bit-flipping và Padding Oracle Attack thường gặp trên các ứng dụng nền Web.

  3. Cơ chế truyền thông thời gian thực thế hệ mới: Tận dụng cơ chế đàm phán thông minh của ASP.NET SignalR giúp giảm kích thước gói tin điều khiển từ 871 bytes (HTTP request) xuống chỉ còn 2 bytes (WebSocket frame), tiết kiệm 99.7% chi phí băng thông đường truyền.

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

Kịch bản ứng dụng trong thực tế

  • Hệ thống liên lạc nội bộ của doanh nghiệp tài chính/ngân hàng: Yêu cầu bảo mật tuyệt đối thông tin trao đổi giữa các phòng ban mà không sử dụng máy chủ đám mây của bên thứ ba.
  • Hệ thống tư vấn y tế từ xa (Telemedicine Chat): Bảo vệ dữ liệu bệnh án và quyền riêng tư của bệnh nhân theo các tiêu chuẩn nghiêm ngặt (tương đương chuẩn HIPAA).
  • Hệ thống phòng điều khiển tác chiến/an ninh: Ứng dụng trong môi trường mạng quân sự nội bộ (Air-gapped Network) với hạ tầng RootCA tự quản.

Hướng dẫn triển khai hệ thống (Deployment Guide)

1. Yêu cầu hệ thống tối thiểu:

  • Server: Windows Server 2012 R2 hoặc mới hơn, 4 vCPU, 8GB RAM, IIS 8.5+, .NET Framework 4.7.2+, Microsoft SQL Server 2014+.
  • Client: Trình duyệt hỗ trợ HTML5 & ECMAScript 6 (Google Chrome 60+, Mozilla Firefox 55+, Microsoft Edge 79+).

2. Các bước triển khai chi tiết:

  1. Bước 1 - Cấu hình Cơ sở dữ liệu: Chạy tập lệnh SQL tạo cơ sở dữ liệu SecureChatDB, tạo bảng tbl_UserAccount và cấp quyền cho tài khoản dịch vụ IIS.
  2. Bước 2 - Thiết lập Dịch vụ Chứng thực (Active Directory Certificate Services): Cài đặt tính năng Certification Authority (CA), tạo Root Certificate, xuất bản chứng chỉ Web Server với thuộc tính Server Authentication (OID: 1.3.6.1.5.5.7.3.1).
  3. Bước 3 - Xuất bản ứng dụng từ Visual Studio: Chọn cấu hình Release, thực hiện Publish ứng dụng ra thư mục cục bộ.
  4. Bước 4 - Cấu hình Web Server IIS:
    • Tạo Website mới trỏ tới thư mục mã nguồn.
    • Thêm Binding HTTPS trên cổng 443, gán chứng thư số đã cấp ở Bước 2.
    • Bật tính năng WebSocket Protocol trong mục Web Server (IIS) > Web Server > Application Development.
    • Cấu hình thuộc tính SSL: Chọn Require SSL để ép buộc tất cả lưu lượng đi qua kênh mã hóa.

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

Hạn chế kỹ thuật hiện tại

  • Khóa mầm AES-CTR hiện vẫn phải được người dùng tự thỏa thuận thủ công qua một kênh liên lạc phụ (Out-of-band communication), chưa tích hợp giao thức trao đổi khóa tự động.
  • Chưa hỗ trợ chức năng gửi tệp đính kèm đa phương tiện dung lượng lớn hoặc gọi thoại/video thời gian thực.
  • Ứng dụng tập trung vào kiến trúc Web Forms, chưa tối ưu hóa dạng SPA (Single Page Application) hiện đại như React hoặc Vue.js.

Hướng phát triển trong tương lai

  • Tích hợp giao thức trao đổi khóa Diffie-Hellman dựa trên đường cong Elliptic (ECDH): Cho phép hai máy trạm tự động tạo khóa phiên an toàn trên kênh công cộng mà không cần chia sẻ trước mật khẩu mầm.
  • Nâng cấp sang .NET 8 / ASP.NET Core SignalR: Tận dụng hiệu năng cao của Kestrel Server, tăng khả năng mở rộng (Scalability) lên hàng triệu kết nối đồng thời thông qua Redis Backplane.
  • Tích hợp chuẩn WebRTC: Mở rộng ứng dụng hỗ trợ Video Call mã hóa đầu cuối (E2EE) ngang hàng (Peer-to-Peer).

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

  • Sinh viên & Học viên ngành An toàn thông tin / Công nghệ thông tin: Là tài liệu tham khảo thực tế về cách thức kết hợp lý thuyết mật mã học (AES, SSL/TLS, SHA) vào một sản phẩm phần mềm hoàn chỉnh.
  • Lập trình viên Full-stack: Nắm bắt kiến trúc kết nối thời gian thực sử dụng ASP.NET SignalR, cơ chế đàm phán kết nối và kỹ thuật mã hóa dữ liệu phía Client với JavaScript.
  • Doanh nghiệp vừa và nhỏ (SMEs): Bản thiết kế có thể sử dụng ngay để xây dựng hệ thống chat nội bộ bảo mật cao với chi phí bản quyền và phần cứng tối thiểu.
  • Nhà nghiên cứu bảo mật: Mô hình thực nghiệm cung cấp dữ liệu đối sánh rõ ràng giữa lưu lượng bản rõ và bản mã trên công cụ phân tích gói tin Wireshark.

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

1. Yêu cầu kỹ thuật tối thiểu để triển khai ứng dụng trên máy chủ là gì?

Máy chủ cần chạy tối thiểu Windows Server 2012 với IIS 8.5, cài đặt .NET Framework 4.7.2 trở lên, hỗ trợ giao thức WebSocket và có hệ quản trị Microsoft SQL Server 2012 trở lên để lưu trữ tài khoản người dùng.

2. Giới hạn chịu tải của hệ thống và giải pháp mở rộng quy mô (Scalability) là gì?

Ở kiến trúc đơn máy chủ hiện tại, ứng dụng đáp ứng tốt 2.000 - 5.000 kết nối đồng thời. Để mở rộng lên hàng chục ngàn người dùng, hệ thống có thể triển khai cụm Web Server (Web Farm) kết hợp với Azure SignalR Service hoặc sử dụng Redis Backplane / SQL Server Service Broker để đồng bộ hóa tin nhắn giữa các node máy chủ.

3. Tại sao lại cần mã hóa AES-CTR phía Client khi đã có kết nối bảo mật HTTPS/WSS?

HTTPS/WSS chỉ bảo vệ dữ liệu trên đường truyền giữa Client và Server. Tại Server, dữ liệu sẽ được giải mã về dạng bản rõ. Việc áp dụng thêm AES-CTR phía Client giúp hiện thực hóa mô hình End-to-End Encryption (E2EE), ngăn chặn triệt để nguy cơ lộ lọt dữ liệu nếu máy chủ ứng dụng bị tấn công hoặc do quản trị viên máy chủ lạm quyền.

4. Chi phí bảo trì và vận hành hệ thống ước tính như thế nào?

Nếu triển khai On-Premises trên hạ tầng có sẵn của doanh nghiệp, chi phí vận hành phần mềm gần như bằng 0 do sử dụng các công nghệ tích hợp sẵn của hệ sinh thái Microsoft (IIS, SignalR mã nguồn mở, CSDL Express/Standard).

5. Tại sao đồ án lựa chọn thuật toán AES chế độ CTR thay vì chế độ CBC hay ECB?

Chế độ ECB làm rò rỉ mẫu cấu trúc dữ liệu và dễ bị tấn công lặp lại. Chế độ CBC yêu cầu cơ chế đệm (padding) và không thể mã hóa/giải mã song song. Chế độ CTR chuyển đổi mã khối thành mã dòng, có tốc độ xử lý nhanh nhất, cho phép tính toán song song, không cần padding và loại bỏ hoàn toàn nguy cơ tấn công Padding Oracle.

Kết luận

Đồ án tốt nghiệp "Xây dựng ứng dụng Chat có bảo mật trên nền tảng giao diện Web" đã giải quyết xuất sắc bài toán cân bằng giữa tốc độ truyền thông thời gian thực và tiêu chuẩn bảo mật dữ liệu cấp độ quân sự. Bằng việc kết hợp tinh tế giữa nền tảng ASP.NET SignalR với hệ mật mã khối AES-CTR trên máy khách và hạ tầng bảo mật SSL/TLS trên máy chủ, hệ thống loại bỏ hoàn toàn các rủi ro về tấn công nghe lén, giả mạo và can thiệp thông tin. Kết quả thực nghiệm bằng các công cụ an ninh mạng chuyên dụng chứng minh tính đúng đắn, khả thi và độ tin cậy vượt trội của giải pháp, mở ra tiềm năng ứng dụng to lớn trong việc bảo vệ dữ liệu truyền thông số của các tổ chức và doanh nghiệp.