Bối cảnh và vấn đề nghiên cứu
Ứng dụng Web xuất hiện từ năm 1989 do nhà vật lý học Tim Berners-Lee khởi xướng nhằm phục vụ việc trao đổi tài liệu nghiên cứu qua mạng Internet. Trải qua các giai đoạn phát triển từ Web tĩnh, Web động đến các nền tảng Web thời gian thực, số lượng trang web trên toàn cầu đã đạt khoảng 1,94 tỉ vào đầu năm 2019. Trong số các ứng dụng trên nền tảng Web, ứng dụng nhắn tin trực tuyến (Chat) trở thành công cụ phổ biến giúp kết nối người dùng, chia sẻ văn bản, dữ liệu với quy mô hàng trăm triệu người dùng trên các hệ thống như Google Chat, Viber, WhatsApp.
Tuy nhiên, đặc thù trao đổi dữ liệu trực tiếp khiến ứng dụng Chat trên nền Web đối mặt với nhiều nguy cơ mất an toàn thông tin nghiêm trọng như tấn công nghe lén, thu thập dữ liệu, tấn công dựa trên lỗi cấu hình, tấn công chèn mã SQL (SQL Injection) và giả mạo định danh. Việc người dùng truyền dữ liệu không qua mã hóa có thể dẫn đến lộ lọt thông tin riêng tư. Xuất phát từ thực tế đó, tác giả Phạm Văn Anh thực hiệ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" tại Đại học Bách khoa Hà Nội (năm 2022).
Nhiệm vụ nghiên cứu của đồ án được xác định cụ thể như sau:
- Nghiên cứu tổng quan về công nghệ Web, các kỹ thuật trao đổi dữ liệu Web, phân loại ứng dụng Web và các nguy cơ gây mất an toàn thông tin cùng giải pháp phòng ngừa tương ứng.
- Phân tích các giải pháp bảo mật dữ liệu chuyên sâu cho ứng dụng Chat trên nền tảng Web, bao gồm giải pháp mã hóa dữ liệu tại tầng ứng dụng (thuật toán AES và các chế độ làm việc) và giải pháp sử dụng bộ giao thức SSL/TLS.
- Thiết kế, xây dựng, triển khai và thực nghiệm ứng dụng Chat thời gian thực trên nền tảng Web có tích hợp xác thực tài khoản (SHA-512), mã hóa dữ liệu tầng ứng dụng (AES-CTR) và mã hóa kênh truyền (SSL/TLS trên máy chủ Windows Server 2012).
Đối tượng và phạm vi nghiên cứu:
- Đối tượng nghiên cứu: Các cơ chế truyền thông Web thời gian thực (Regular HTTP, AJAX Long-Polling, WebSockets/SignalR); các hệ mật mã đối xứng (AES) và các chế độ hoạt động khối (ECB, CBC, CFB, OFB, CTR); bộ giao thức bảo mật SSL/TLS.
- Phạm vi không gian và triển khai thực nghiệm: Hệ thống thử nghiệm bao gồm 01 máy chủ chạy hệ điều hành Windows Server 2012 (tích hợp IIS, DNS, dịch vụ cấp chứng thực số CA, hệ quản trị cơ sở dữ liệu Microsoft SQL Server) và 02 máy trạm chạy hệ điều hành Windows 10 (sử dụng trình duyệt Google Chrome và Microsoft Edge).
- Phạm vi thời gian: Đồ án được hoàn thành và nghiệm thu vào năm 2022.
Cơ sở lý thuyết và phương pháp
Đồ án dựa trên các khung lý thuyết, tiêu chuẩn mật mã học và công nghệ truyền thông mạng chuẩn hóa quốc tế:
- Khung lý thuyết ứng dụng Web và kỹ thuật truyền thông thời gian thực: Lý thuyết mô hình dịch vụ Web (Web Server, Web Client, Webpage, Website); phân loại ứng dụng Web (tĩnh, động, thời gian thực); các kỹ thuật truyền tải dữ liệu gồm Regular HTTP, AJAX Long-Polling, HTML5 WebSockets và thư viện ASP.NET SignalR.
- Lý thuyết an toàn thông tin trên nền tảng Web: Năm mục tiêu an ninh thông tin cơ bản gồm tính xác thực (Authentication), tính bí mật (Confidentiality), tính toàn vẹn (Integrity), tính chống chối bỏ (Non-repudiation) và tính sẵn sàng (Availability).
- Tiêu chuẩn mã hóa dữ liệu tiên tiến (AES): Thuật toán Rijndael được Viện Tiêu chuẩn và Kỹ thuật Quốc gia Hoa Kỳ (NIST) chuẩn hóa năm 2000. Cấu trúc mã khối với độ dài khối 128 bit ($N_b = 4$), hỗ trợ kích thước khóa 128 bit (10 vòng, $N_k = 4$), 192 bit (12 vòng, $N_k = 6$) và 256 bit (14 vòng, $N_k = 8$). Bốn phép biến đổi trạng thái trong mỗi vòng gồm: SubBytes (thay thế byte bằng S-box), ShiftRows (dịch chuyển hàng), MixColumns (trộn cột) và AddRoundKey (cộng khóa vòng).
- Lý thuyết các chế độ hoạt động của mã khối: Nghiên cứu 5 chế độ hoạt động theo chuẩn NIST gồm Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB) và Counter (CTR).
- Bộ giao thức SSL/TLS: Lịch sử phát triển (SSL 1.0, SSL 2.0 năm 1995, SSL 3.0 năm 1996, TLS 1.0 theo RFC 2246 năm 1999, TLS 1.1 theo RFC 4346 năm 2006, TLS 1.2 năm 2008, TLS 1.3 năm 2018). Cấu trúc các giao thức thành phần gồm: SSL Record Protocol, SSL Handshake Protocol, SSL ChangeCipherSpec Protocol, SSL Alert Protocol và SSL Application Data Protocol.
Phương pháp nghiên cứu được áp dụng:
- Phương pháp phân tích - tổng hợp lý thuyết: Phân tích cấu trúc giao thức, so sánh chi phí tiêu đề (header overhead) giữa HTTP và WebSockets; so sánh ưu nhược điểm và đặc tính lan sai (error propagation) của các chế độ hoạt động mã khối để chọn lựa giải pháp tối ưu cho ứng dụng thời gian thực.
- Phương pháp thiết kế và phát triển hệ thống phần mềm: Xây dựng ứng dụng theo kiến trúc phân tầng (Client - Web/Application Server - Database Server), áp dụng mô hình lập trình OWIN/SignalR Hub và mô hình xác thực dựa trên phiên kết hợp hàm băm mật mã.
- Phương pháp thực nghiệm kiểm thử an ninh: Thực hiện kiểm thử bắt gói tin mạng bằng công cụ sniffing trong hai kịch bản: hệ thống chưa kích hoạt cơ chế bảo mật và hệ thống đã kích hoạt đầy đủ hai lớp bảo mật (AES-CTR và SSL/TLS).
Nguồn dữ liệu nghiên cứu: Các đặc tả kỹ thuật RFC của IETF, tiêu chuẩn của NIST, tài liệu của dự án bảo mật OWASP, tài liệu phát triển phần mềm chính thức của Microsoft (.NET Framework, SignalR, SQL Server) và dữ liệu hội thoại thực nghiệm trên hệ thống thử nghiệm cục bộ.
Thiết kế và triển khai
Kiến trúc hệ thống và mô hình triển khai
Mô hình triển khai ứng dụng Chat bảo mật gồm 3 thành phần chính:
- Client (Trình duyệt Web): Chạy trên máy trạm Windows 10 (Google Chrome, Microsoft Edge), chứa thành phần SignalR Proxy để lắng nghe sự kiện đẩy từ máy chủ và tích hợp thư viện JavaScript Crypto thực hiện mã hóa/giải mã AES-CTR trực tiếp tại máy người dùng.
- Web Server & Application Server: Máy chủ Windows Server 2012 cài đặt Internet Information Services (IIS), Domain Name System (DNS), Active Directory Certificate Services (RootCA) và môi trường ASP.NET. Phía máy chủ chứa SignalR Hub đóng vai trò tiếp nhận bản mã và phân phối tin nhắn đến các máy trạm theo thời gian thực mà không giải mã nội dung.
- Database Server: Hệ quản trị cơ sở dữ liệu Microsoft SQL Server lưu trữ cơ sở dữ liệu
LoginDB phục vụ việc đăng ký và xác thực tài khoản.
| Thành phần |
Công nghệ / Nền tảng |
Chức năng chính |
| Giao diện người dùng |
HTML, CSS, JavaScript |
Hiển thị giao diện chat, tiếp nhận thao tác, nhập mầm sinh khóa |
| Mã hóa tầng ứng dụng |
Thư viện Crypto (aes.js, aes-ctr.js) |
Mã hóa bản rõ trước khi gửi, giải mã bản mã khi nhận bằng AES-CTR |
| Truyền thông thời gian thực |
ASP.NET SignalR (Hub & Proxy) |
Thiết lập kết nối liên tục, tự động thương lượng transport, đẩy dữ liệu hai chiều |
| Máy chủ ứng dụng |
ASP.NET, C#, OWIN Startup |
Xử lý logic nghiệp vụ, điều phối thông điệp chat, quản lý phiên làm việc |
| Xác thực & Cơ sở dữ liệu |
Microsoft SQL Server, SHA-512 |
Lưu trữ thông tin tài khoản, băm mật khẩu bảo mật (HASHBYTES) |
| Bảo mật tầng truyền vận |
IIS, CA, Giao thức SSL/TLS |
Cấp phát chứng thư số cho máy chủ, mã hóa đường truyền mạng (HTTPS) |
Quá trình xây dựng các module chức năng
- Module Chat thời gian thực:
- Khởi tạo dự án ASP.NET Web Application (.NET Framework Empty) trên Microsoft Visual Studio 2019.
- Cài đặt thư viện
Microsoft.AspNet.SignalR thông qua NuGet Package Manager Console.
- Xây dựng lớp
ChatHub.cs kế thừa từ lớp Hub của SignalR nhằm quản lý kết nối và cung cấp phương thức gửi nhận tin nhắn đồng loạt (quảng bá đến các client).
- Cấu hình lớp
Startup.cs tích hợp OWIN với phương thức ánh xạ app.MapSignalR().
- Thiết kế giao diện trang chủ
Best.aspx chứa giao diện khung chat, tiếp nhận tên người dùng và vùng nhập nội dung.
- Module Đăng ký và Xác thực người dùng:
- Khởi tạo cơ sở dữ liệu
LoginDB trong Microsoft SQL Server với bảng thông tin chi tiết: Username, Password, Fullname, Phone, Email, Birthday.
- Cơ chế băm mật khẩu: Mật khẩu người dùng được băm trước khi lưu trữ bằng hàm SHA-512 thông qua câu lệnh
HASHBYTES('SHA2_512', 'mat_khau') trong SQL Server và lớp SHA512 trong .NET Framework.
- Xây dựng trang
Login.aspx và lớp xử lý Login.cs để xác thực tài khoản; cấp phiên làm việc (Session) sau khi đăng nhập thành công, chặn truy cập trực tiếp vào hệ thống chat nếu chưa xác thực.
- Triển khai cơ chế bảo mật hai lớp:
- Lớp 1 (Mã hóa tầng ứng dụng): Tích hợp thư viện JavaScript mật mã vào trang
Best.aspx. Hai người dùng thỏa thuận trước một mầm sinh khóa (seed key) bí mật và nhập vào giao diện. Khi Client 1 nhập tin nhắn, hệ thống sử dụng thuật toán AES chế độ CTR mã hóa bản rõ thành bản mã rồi mới truyền đến SignalR Hub. Máy chủ nhận bản mã và chuyển tiếp cho Client 2; Client 2 nhận bản mã và tự động giải mã về bản rõ nhờ mầm sinh khóa tương ứng.
- Lớp 2 (Bảo mật kênh truyền SSL/TLS): Cấu hình dịch vụ chứng thực số CA trên Windows Server 2012, tạo yêu cầu cấp chứng chỉ (Certificate Request), gửi yêu cầu lên trang quản trị RootCA, cấp phát và cài đặt chứng thư số vào IIS. Cấu hình ràng buộc trang web chat phải hoạt động qua giao thức an toàn (Require SSL).
Nội dung chính theo từng chương
Chương 1: Ứng dụng Web và các nguy cơ mất an toàn thông tin
Chương 1 hệ thống hóa các kiến thức nền tảng về công nghệ Web, cơ chế hoạt động của Web Server, Web Client, Webpage và Website. Tác giả đi sâu phân tích cơ chế truyền dữ liệu qua các giao thức và kỹ thuật:
- Regular HTTP: Hoạt động theo mô hình yêu cầu - phản hồi tuần tự do máy trạm chủ động khởi tạo; máy chủ không thể tự ý đẩy dữ liệu xuống máy trạm.
- AJAX Long-Polling: Máy trạm gửi yêu cầu và máy chủ giữ kết nối cho đến khi có dữ liệu mới thì mới phản hồi; sau đó máy trạm lập tức mở yêu cầu mới.
- HTML5 WebSockets: Thiết lập kết nối song công hai chiều (Full Duplex) liên tục giữa client và server thông qua một liên kết WebSocket ban đầu. Tác giả chỉ ra số liệu so sánh kỹ thuật: kích thước phần tiêu đề (header) của yêu cầu/phản hồi HTTP tiêu chuẩn chiếm khoảng 871 byte, trong khi kích thước tiêu đề của WebSocket sau khi mở kết nối thành công chỉ chiếm 2 byte.
Chương 1 cũng phân loại ứng dụng Web thành 3 nhóm (Web tĩnh, Web động, Web thời gian thực) và giới thiệu các Web Framework tiêu biểu như Ruby on Rails, CakePHP, ASP.NET. Đồng thời, chương này phân tích các dạng tấn công điển hình (nghe lén, lỗi cấu hình, SQL Injection) và đề xuất 5 giải pháp phòng chống bám sát các mục tiêu an toàn thông tin (xác thực qua chứng chỉ/thông tin định danh, bí mật qua mã hóa dữ liệu và SSL/TLS, toàn vẹn qua mã MAC/HMAC, chống chối bỏ qua chữ ký số, sẵn sàng qua cân bằng tải và sao lưu dự phòng).
Chương 2: Giải pháp bảo mật trong ứng dụng Chat trên nền tảng Web
Chương 2 tập trung giải quyết các bài toán an ninh đặc thù của ứng dụng Chat, bao gồm nguy cơ nghe lén, thu thập dữ liệu, giả mạo máy chủ và sửa đổi thông tin. Tác giả đề xuất kết hợp hai giải pháp trọng tâm:
- Mã hóa dữ liệu tại tầng ứng dụng sử dụng hệ mật AES:
- Phân tích cấu trúc toán học của AES: Hoạt động trên khối nhị phân 128 bit, kích thước khóa 128/192/256 bit tương ứng với 10/12/14 vòng biến đổi. Trạng thái ma trận 4 dòng, $N_b$ cột ($N_b = 4$).
- Đánh giá và so sánh chi tiết 5 chế độ hoạt động của mã khối:
| Chế độ mã khối |
Cơ chế hoạt động chính |
Tính chất phụ thuộc móc xích |
Hiện tượng lan sai (Error propagation) |
Đánh giá phù hợp với ứng dụng Chat |
| ECB |
Mã hóa độc lập từng khối rõ với cùng một khóa |
Các khối hoàn toàn độc lập; khối rõ giống nhau tạo khối mã giống nhau |
Lỗi bit trong một khối mã chỉ ảnh hưởng giải mã duy nhất khối đó |
Yếu nhất, dễ bị tấn công dùng lại, không an toàn |
| CBC |
Khối rõ được XOR với khối mã trước đó (hoặc IV) trước khi mã hóa |
Bản mã $c_j$ phụ thuộc vào khối rõ $x_j$ và tất cả các khối rõ đứng trước |
Lỗi một bit ở $c_j$ làm hỏng hoàn toàn giải mã khối $c_j$ và ảnh hưởng khối $c_{j+1}$ |
Độ an toàn tốt nhưng xử lý tuần tự, không hỗ trợ song song |
| CFB |
Mã hóa thanh ghi dịch (chứa IV/khối mã trước) rồi XOR với bản rõ |
Bản mã $c_j$ phụ thuộc vào $x_j$ và các khối rõ phía trước |
Lỗi bit trong khối mã $c_j$ ảnh hưởng đến giải mã khối đó và $n/r$ khối tiếp theo |
Xử lý dòng, nhưng tuần tự và phụ thuộc trạng thái |
| OFB |
Mã hóa liên tiếp IV để tạo dòng khóa độc lập rồi XOR với bản rõ |
Dòng khóa hoàn toàn độc lập với bản rõ |
Lỗi bit tại $c_j$ chỉ làm đảo đúng vị trí bit tương ứng ở $x_j$, không thể tự đồng bộ nếu mất bit |
Tốt cho ứng dụng phần mềm nhưng không hỗ trợ tính toán song song |
| CTR |
Mã hóa giá trị bộ đếm tăng dần rồi XOR với bản rõ |
Không có phản hồi móc xích giữa các khối bản rõ |
Lỗi bit tại khối mã nào chỉ ảnh hưởng đúng bit tương ứng của khối rõ đó |
Tối ưu nhất: Đơn giản, tính toán song song cả mã hóa lẫn giải mã, tốc độ xử lý nhanh |
Dựa trên các đặc tính trên, tác giả lựa chọn AES-CTR làm chế độ mã hóa cho ứng dụng Chat.
- Bảo mật kênh truyền sử dụng bộ giao thức SSL/TLS:
- Trình bày kiến trúc phân tầng của SSL/TLS nằm giữa tầng ứng dụng và tầng vận chuyển (TCP).
- Phân tích cấu trúc bản ghi SSL Record: Phân đoạn dữ liệu thành các khối tối đa 16 KB, nén dữ liệu, tạo mã MAC và mã hóa. Tiêu đề SSL Record Header bao gồm trường Type (8 bit: 20-ChangeCipherSpec, 21-Alert, 22-Handshake, 23-Application Data), trường Version (16 bit gồm Major và Minor) và trường Length (16 bit).
- Chi tiết quy trình bắt tay SSL Handshake: Gồm các bước gửi
ClientHello, phản hồi ServerHello, gửi khóa công khai máy chủ ServerKeyExchange, kết thúc chào hỏi ServerHelloDone, máy trạm gửi khóa phiên mã hóa RSA/Diffie-Hellman ClientKeyExchange, kích hoạt thông số mật mã qua ChangeCipherSpec và xác nhận hoàn tất qua thông điệp Finished.
- Phân loại các cảnh báo trong giao thức SSL Alert: Cảnh báo mức độ nghiêm trọng (fatal) như
unexpected_message, bad_record_mac, decompression_failure, handshake_failure, illegal_parameter và cảnh báo thông thường (close_notify, bad_certificate, v.v.).
Chương 3: Xây dựng, triển khai và thực nghiệm ứng dụng Chat trên nền tảng giao diện Web có bảo mật
Chương 3 trình bày toàn bộ quy trình hiện thực hóa giải pháp từ cấu hình môi trường, lập trình mã nguồn, cấu hình hạ tầng đến thực nghiệm đánh giá an ninh:
- Nguyên lý hoạt động và lựa chọn kết nối của SignalR: Trình bày cơ chế SignalR Hub (trên server) và SignalR Proxy (trên client). Thứ tự tự động lựa chọn phương thức vận chuyển của SignalR được phân tích theo quy trình logic:
- Kiểm tra nếu trình duyệt là Internet Explorer phiên bản $\le 8$ hoặc đã cấu hình JSONP thì sử dụng AJAX Long-Polling.
- Nếu không, kiểm tra hỗ trợ WebSockets: Nếu client hỗ trợ CORS, cả client và server đều hỗ trợ WebSockets thì sử dụng WebSockets.
- Nếu không thỏa mãn WebSockets, chuyển sang kiểm tra Server-Sent Events (SSE); nếu hỗ trợ thì dùng SSE.
- Nếu SSE không khả dụng, kiểm tra nếu là trình duyệt Internet Explorer phiên bản $> 9$ thì sử dụng Forever Frame.
- Nếu tất cả các phương thức trên đều không khả dụng, SignalR chuyển về sử dụng AJAX Long-Polling.
- Quy trình triển khai hệ thống: Thiết lập project trên Visual Studio 2019, cài đặt SignalR v2, lập trình
ChatHub.cs, Startup.cs, thiết kế Login.aspx, Best.aspx, cấu hình mã hóa JavaScript phía client, xây dựng cơ sở dữ liệu LoginDB trên SQL Server với mật khẩu băm SHA-512, xuất bản ứng dụng lên IIS và cấu hình chứng thư số CA trên Windows Server 2012.
- Kịch bản thực nghiệm và đánh giá an ninh:
- Thực nghiệm chương trình Chat chưa có bảo mật: Hai client trao đổi tin nhắn văn bản thông thường. Sử dụng công cụ bắt gói tin trên đường truyền mạng cho thấy toàn bộ nội dung tin nhắn được truyền dưới dạng bản rõ (plaintext), kẻ tấn công có thể đọc trộm và thu thập dữ liệu dễ dàng.
- Thực nghiệm chương trình Chat có bảo mật: Kích hoạt mã hóa AES-CTR tại client và giao thức SSL/TLS trên IIS. Kết quả bắt gói tin cho thấy luồng dữ liệu trên đường truyền được đóng gói hoàn toàn trong các gói tin
TLSv1 Application Data. Đồng thời, dữ liệu sau khi giải nén gói tin TLS tại máy chủ trung gian vẫn chỉ là chuỗi bản mã AES-CTR vô nghĩa đối với bên thứ ba, chỉ máy trạm đích sở hữu đúng mầm sinh khóa mới giải mã thành công về bản rõ.
Kết quả và đóng góp
Kết quả nghiên cứu và thực nghiệm
- Xây dựng hoàn chỉnh ứng dụng Web Chat thời gian thực đa người dùng dựa trên ASP.NET SignalR với giao diện web thân thiện, hoạt động ổn định trên các trình duyệt hiện đại (Google Chrome, Microsoft Edge).
- Triển khai thành công hệ thống xác thực người dùng chặt chẽ: Dữ liệu mật khẩu lưu trữ trong Microsoft SQL Server được băm một chiều an toàn bằng thuật toán SHA-512 (
HASHBYTES), ngăn chặn lộ lọt mật khẩu ngay cả khi cơ sở dữ liệu bị truy cập trái phép.
- Tích hợp thành công mô hình bảo mật dữ liệu hai lớp:
- Lớp mã hóa đầu cuối tại tầng ứng dụng sử dụng thuật toán AES chế độ CTR, xử lý phân tán trực tiếp trên trình duyệt bằng JavaScript, bảo vệ bí mật nội dung hội thoại trước cả máy chủ trung gian.
- Lớp mã hóa kênh truyền sử dụng giao thức SSL/TLS thông qua chứng thư số cấp bởi dịch vụ CA nội bộ trên Windows Server 2012, bảo vệ toàn diện tính toàn vẹn và xác thực của phiên giao dịch.
- Kết quả thực nghiệm kiểm thử bắt gói tin chứng minh hệ thống có khả năng phòng chống triệt để các hành vi tấn công nghe lén (packet sniffing) và thu thập thông tin trái phép trên đường truyền.
Đóng góp kỹ thuật của đồ án
- Đề xuất và hiện thực hóa mô hình kết hợp giữa cơ chế mã hóa đối xứng tại client (AES-CTR) và mã hóa kênh truyền (SSL/TLS) dành riêng cho ứng dụng web thời gian thực, giải quyết hài hòa giữa yêu cầu bảo mật cao và yêu cầu giảm thiểu độ trễ truyền thông.
- Phân tích và chứng minh tính ưu việt của chế độ CTR (Counter) so với các chế độ khối truyền thống (ECB, CBC, CFB, OFB) trong môi trường xử lý song song trên ứng dụng web.
- Cung cấp tài liệu hướng dẫn kỹ thuật chi tiết từ khâu lập trình ứng dụng với ASP.NET SignalR đến khâu cấu hình hạ tầng bảo mật mạng máy chủ doanh nghiệp (IIS, DNS, Active Directory Certificate Services).
Hạn chế và hướng nghiên cứu tiếp
Hạn chế của đề tài
- Cơ chế phân phối khóa mã hóa: Việc thiết lập khóa mã hóa AES-CTR giữa các người dùng trong phòng chat vẫn dựa trên cơ chế người dùng tự thỏa thuận và nhập thủ công mầm sinh khóa (seed key) trên giao diện web, chưa được tự động hóa thông qua các giao thức trao đổi khóa công khai (như Diffie-Hellman hoặc hạ tầng khóa công khai PKI tích hợp trực tiếp).
- Phạm vi chức năng ứng dụng: Ứng dụng mới tập trung vào tính năng nhắn tin văn bản (text chat) dạng phòng chat chung (chat room/quảng bá), chưa mở rộng các tính năng chat riêng tư từng cặp người dùng, chia sẻ tập tin, hình ảnh hoặc đa phương tiện.
- Quy mô môi trường thực nghiệm: Hệ thống mới được thử nghiệm trong mô hình mạng cục bộ (LAN) với quy mô 01 máy chủ Windows Server 2012 và 02 máy trạm client; chưa tiến hành đánh giá hiệu năng chịu tải với số lượng kết nối đồng thời lớn trên môi trường Internet thực tế.
Hướng nghiên cứu và phát triển tiếp
- Tích hợp các giao thức trao đổi khóa tự động và an toàn (như Diffie-Hellman, ECDH hoặc chữ ký số RSA) vào ứng dụng để tự động thiết lập khóa phiên mà không cần người dùng nhập mầm sinh khóa thủ công.
- Mở rộng chức năng ứng dụng: Bổ sung tính năng chat cá nhân 1-1, phân quyền phòng chat, mã hóa tệp đính kèm và truyền thông giọng nói/video thời gian thực.
- Nâng cấp kiến trúc mở rộng (scalability): Tích hợp giải pháp cân bằng tải cho SignalR bằng cách sử dụng Redis Backplane hoặc SQL Server Service Broker nhằm hỗ trợ phục vụ hàng ngàn đến hàng chục ngàn người dùng đồng thời.
Giá trị tham khảo
Đồ án tốt nghiệp là tài liệu tham khảo có giá trị kỹ thuật và thực tiễn đối với:
- Sinh viên và học viên ngành Công nghệ thông tin, An toàn thông tin, Kỹ thuật phần mềm: Là tài liệu tham khảo toàn diện khi thực hiện đồ án môn học, khóa luận tốt nghiệp liên quan đến lập trình ứng dụng Web thời gian thực, mật mã học ứng dụng và an ninh mạng.
- Kỹ sư phát triển phần mềm Web: Cung cấp quy trình tích hợp thư viện ASP.NET SignalR với OWIN, phương pháp nhúng thư viện mật mã JavaScript (
CryptoJS) để xử lý dữ liệu nhạy cảm phía máy khách và phương pháp băm mật khẩu bảo mật trong SQL Server bằng SHA-512.
- Quản trị viên hệ thống mạng: Cung cấp hướng dẫn chi tiết về cấu hình hạ tầng dịch vụ mạng trên Windows Server, bao gồm thiết lập dịch vụ chứng thực số (Certificate Authority), xuất bản ứng dụng trên IIS và kích hoạt chứng thư số SSL/TLS cho trang web doanh nghiệp.
Các phần nội dung đáng tham khảo nhất trong văn bản:
- Phần phân tích lý thuyết, so sánh chi tiết 5 chế độ hoạt động của thuật toán mã khối AES (Mục 2.2.2).
- Sơ đồ logic và nguyên lý tự động lựa chọn phương thức truyền tải kết nối của SignalR (Mục 3.1.2).
- Quy trình triển khai chi tiết từng bước xây dựng SignalR Hub, OWIN Startup và cấu hình mã hóa hai lớp (Mục 3.4 và 3.5).
Câu hỏi thường gặp
1. Tại sao tác giả lựa chọn chế độ bộ đếm CTR cho thuật toán AES thay vì các chế độ ECB, CBC, CFB hay OFB?
Chế độ ECB yếu nhất và dễ bị tấn công dùng lại; chế độ CBC và CFB có cơ chế phản hồi móc xích khiến việc mã hóa/giải mã phải thực hiện tuần tự và lan sai khi có lỗi bit; chế độ OFB độc lập với bản rõ nhưng không hỗ trợ tính toán song song. Trong khi đó, chế độ CTR gắn thuật toán mã khối với giá trị bộ đếm tăng dần rồi XOR với bản rõ. Do không có vòng lặp phản hồi, quá trình mã hóa và giải mã có thể thực hiện song song hoàn toàn, giúp tốc độ xử lý rất nhanh, cấu trúc đơn giản, ít độ trễ và phù hợp tối ưu với các ứng dụng truyền thông thời gian thực trên nền web.
2. Kích thước tiêu đề (header) của HTML5 WebSockets có ưu thế gì so với giao thức HTTP truyền thống?
Theo số liệu phân tích trong đồ án, một tiêu đề yêu cầu/phản hồi (request/response header) của giao thức HTTP tiêu chuẩn (kể cả khi kết hợp AJAX) có kích thước xấp xỉ 871 byte cho mỗi lần gửi. Trong khi đó, với HTML5 WebSockets, sau khi kết nối hai chiều được thiết lập thành công, kích thước tiêu đề của mỗi gói tin truyền tải chỉ còn 2 byte, giúp giảm thiểu tối đa độ trễ đường truyền và tiết kiệm băng thông mạng.
3. Cơ chế xác thực tài khoản và lưu trữ mật khẩu người dùng trong đồ án được thiết kế như thế nào?
Ứng dụng sử dụng cơ sở dữ liệu LoginDB trên Microsoft SQL Server. Mật khẩu của người dùng không bao giờ được lưu trữ dưới dạng bản rõ mà được chuyển đổi thành chuỗi băm thông qua hàm băm mật mã SHA-512 (HASHBYTES('SHA2_512', '...')). Khi người dùng đăng nhập, mật khẩu nhập vào sẽ được băm tại máy khách/máy chủ bằng lớp SHA512 của .NET rồi so sánh với chuỗi băm trong cơ sở dữ liệu. Sau khi khớp thông tin, hệ thống sẽ khởi tạo phiên làm việc (Session) để cấp quyền truy cập vào giao diện chat.
4. Mô hình bảo mật hai lớp của ứng dụng hoạt động theo trình tự cụ thể nào khi truyền nhận tin nhắn?
Khi Client 1 gửi tin nhắn:
- Lớp 1 (Tầng ứng dụng): Nội dung bản rõ được mã hóa ngay trên trình duyệt bằng thuật toán AES-CTR với mầm sinh khóa thỏa thuận trước, tạo ra bản mã.
- Lớp 2 (Tầng truyền vận): Bản mã được gửi đi qua kết nối bảo mật HTTPS, tại đây giao thức SSL/TLS trên máy chủ IIS tiếp tục đóng gói và mã hóa gói tin ở mức mạng.
- Tại máy chủ: SignalR Hub tiếp nhận gói tin SSL/TLS, giải mã tầng truyền vận nhưng dữ liệu bên trong vẫn là bản mã AES-CTR; máy chủ đẩy bản mã này sang Client 2.
- Tại Client 2: SignalR Proxy tiếp nhận bản mã, sau đó thư viện JavaScript trên trình duyệt của Client 2 thực hiện giải mã AES-CTR bằng mầm sinh khóa tương ứng để thu lại bản rõ ban đầu.
5. Thứ tự ưu tiên mà SignalR sử dụng để lựa chọn phương thức truyền tải (transport) là gì?
SignalR tự động thương lượng kết nối theo thứ tự ưu tiên:
- WebSockets: Được ưu tiên cao nhất nếu cả client và server đều hỗ trợ HTML5 WebSockets và client hỗ trợ CORS.
- Server-Sent Events (SSE): Sử dụng khi WebSockets không khả dụng nhưng trình duyệt hỗ trợ SSE (hầu hết các trình duyệt trừ Internet Explorer).
- Forever Frame: Sử dụng riêng cho trình duyệt Internet Explorer phiên bản $> 9$ khi không dùng được WebSockets.
- AJAX Long-Polling: Phương thức dự phòng cuối cùng, được sử dụng cho Internet Explorer $\le 8$, khi có cấu hình JSONP, hoặc khi cả 3 phương thức trên đều không được hỗ trợ.
Kết luận
Đồ án tốt nghiệp của tác giả Phạm Văn Anh đã giải quyết thành công bài toán xây dựng ứng dụng nhắn tin thời gian thực an toàn trên nền tảng Web thông qua việc kết hợp công nghệ ASP.NET SignalR với mô hình bảo mật hai lớp. Đề tài đã hệ thống hóa sâu sắc cơ sở lý thuyết về mã khối AES, chế độ CTR, bộ giao thức SSL/TLS và các cơ chế truyền thông web hiện đại. Sản phẩm phần mềm được triển khai và thực nghiệm hoàn chỉnh trên môi trường máy chủ Windows Server 2012 và cơ sở dữ liệu SQL Server, chứng minh khả năng chống nghe lén và bảo vệ toàn vẹn dữ liệu hiệu quả trong môi trường mạng.