Luận án Nghiên cứu phát triển giải pháp nâng cao an toàn trong mạng “Internet of things”

 đánh giá kết quả.
An ninh định tuyến trong IoT
Hình 2.1. Mô hình đồ thị DAG của giao thức RPL
Hạn chế bảo mật của giao thức RPL: Không có cơ chế an toàn bảo mật hơn được thiết kế theo phiên bản hiện tại của tiêu chuẩn RPL.
Tấn công DoS trong giao thức RPL
RPL rất dễ bị tổn hại trước các cuộc tấn công DoS nếu so sánh với các giao thức mạng truyền thống như RIP hoặc OSPF vì: Việc xác định đường định tuyến cố định và ít thay đổi khiến cho kẻ tấn công dễ dàng tái sử dụng các kết quả thám thính cho nhiều đợt tấn công DoS. Cấu trúc hình cây DAG khiến cho kẻ tấn công dễ dàng lần ra nút coordinator vì mọi định tuyến đều dẫn đến nút này. Nút coordinator là một thành phần quan trọng của mạng WSN, kẻ tấn công càng ở gần nút gốc cây DAG, hậu quả của cuộc tấn công càng nghiêm trọng.
Các tiêu chí đo đạc và đánh giá hiệu năng mạng
Tỉ lệ truyền nhận thành công (PDR)
Việc xác định số gói tin mà một nút gửi đi hoặc nhận được không khó, nhưng biết gói tin mà nút đó gửi đi là đến nút nào thì không đơn giản. Tính PDR của toàn mạng, ta sử dụng công thức: PDR= RS x 100 (1)
Trong đó:
R: Tổng số gói tin mà tất cả các nút nhận được
S: Tổng số gói tin mà tất cả các nút gửi đi.
Đơn vị của PDR là %
Độ trễ gói tin (Latency)
Latency của một nút. Latency= i=1nTRi-TSiDin (2); Trong đó:
n: Tổng số gói tin đến được mục tiêu.
i: Số thứ tự gói tin từ 0 tăng thêm 1 với mỗi gói tin tới đích.
TRi – TSi: Thời gian gói tin đó từ khi nó rời khỏi nơi xuất phát cho đến khi đến được nút đo đạc.
Di: Khoảng cách từ nơi gói tin đó xuất phát tới đích đến
Đơn vị của Latency là mili giây/mét (ms/m)
Quãng đường là giá trị có thể tính toán, thời gian gói tin ra vào cũng có thể lần ra từ việc đọc địa chỉ gói tin. 
Năng lượng (E)
Năng lượng mạng cảm biến được tính bằng công thức (3) do các lập trình viên về Contiki trên Github đề xuất: 
E=(Tx x Et+Rx x Er+CPU x Eo+LPM x EI) x τ (3)
Trong đó:
•	Tx: phần trăm giữa thời gian nút đấy thức để gửi một gói tin với tổng thời gian của chương trình.
•	Rx: phần trăm giữa thời gian nút đấy thức để chờ được nhận các gói tin đến với tổng thời gian của chương trình.
•	CPU: Năng lượng CPU tiêu thụ cho chương trình mô phỏng. 
•	LPM: phần trăm giữa thời gian chạy các thuật toán duy trì hoạt động mô phỏng của các nút với tổng thời gian của chương trình. Thông số này cũng cố định với từng cấu hình Hệ điều hành Contiki mỗi lần mô phỏng, không phụ thuộc vào hoạt động mô phỏng.
•	Năng lượng vật lý được đo bằng mili Jun (mJ).
Trong đó Et, Er, Eo, EI và τ là các hằng số và không đổi với mỗi lần thí nghiệm dù là mô phỏng hay thực tế.
Phòng chống tấn công DOS với Overhearing 
Overhearing thực chất là giải pháp phát hiện sớm tấn công, can thiệp cấu hình ngăn chặn ảnh hưởng của tấn công DoS. Các nút sẽ phải nghe xem tất cả các nút hàng xóm gửi, nhận bao nhiêu gói tin. Từ đó, phát hiện ra nút nào có biểu hiện tấn công (gửi quá nhiều gói tin hay có những liên lạc bất hợp pháp với botmaster) và có biện pháp ngăn chặn kịp thời (thường là từ chối giao dịch). 
Ý tưởng cải tiến cơ chế Overhearing
Tận dụng thành quả của cơ chế Overhearing để ngăn chặn và giảm thiệt hại từ cuộc tấn công DoS. Đề xuất thuật toán phát hiện nút Bots trực tiếp bên trong các nút mạng mà không tiêu thụ quá nhiều tài nguyên. Kế thừa giải pháp cách ly nút Bots để duy trì hoạt động bình thường WSN mà vẫn đảm bảo tránh lây nhiễm Bot cũng như hạn chế tác hại tiêu cực của tấn công DoS. Phần tiếp theo, chúng tôi sẽ đề xuất thuật toán phát hiện nút Bots dựa trên số bản tin mà nút đó gửi và nhận.
Cải tiến Overhearing
Nhiệm vụ của cải tiến giải pháp Overhearing là xây dựng một cơ chế cảnh báo nhiều mức về nguy cơ một nút mạng bị nhiễm mã độc và trở thành Bot, xây dựng biện pháp ứng phó nhằm giảm thiểu thiệt hại của các cuộc tấn công DoS trên mạng WSN. Cụ thể, luận án đề xuất một phương pháp dựa vào việc thống kê số gói tin mà một nút gửi hoặc nhận và sử dụng các phương pháp thống kê để phát hiện nút Bot sau đó đưa ra các cảnh báo và quyết định khác nhau về tấn công DoS trên mạng WSN. 
Cụ thể có ba mức cảnh báo được đề xuất dựa trên tỉ lệ Báo động giả (False possitive rate), nghĩa là một nút không phải là Bot nhưng vẫn bị gán nhãn là Bot bao gồm:
Mức I – Bất thường
Mức II – Bất thường cảnh báo
Mức III – Phản ứng khẩn cấp
Các mức cảnh báo được thể hiện trong bảng thống kê 2.2 và được xác định bằng các công thức (7), (8), (9), (10) trong phần tiếp theo. Chiến lược của thuật toán là nhìn nhận và xử lý cách ly nút Bot, không bỏ sót nút Bot nào. Luận án tiến hành xây dựng thuật toán phát hiện cảnh báo dựa trên các công đoạn sau:
Bước 1: Tính giá trị trung bình:
Công thức (4) tính giá trị trung bình (µ) đối với số lượng gói tin các nút hàng xóm của nút đấy gửi hoặc nhận. µ= i=1nχiN (4)
Trong đó:
N: Số nút hàng xóm
χi: Số gói tin mà nút hàng xóm đó gửi đi hoặc nhận vào.
i: chỉ số khi duyệt từng nút.
Đơn vị đo của µ là số gói tin.
Bước 2: Tính phương sai và độ lệch chuẩn:
Theo lý thuyết về toán học thống kê, phương sai và độ lệch chuẩn có vai trò đánh giá sự chênh lệch của tất các giá trị với trong tập mẫu. 
σ2= i=1n(χ- µ)2N (5)
Trong đó:
µ: giá trị trung bình tính ở công thức (4)
χi, N và i tương tự các giá trị công thức (4).
Đơn vị đo của σ2 là bình phương số gói tin.
Độ lệch chuẩn hay còn gọi là Standard Deviation. Là đại lượng dùng để phản ánh độ phân tán của các giá trị trong bộ dữ liệu. Thể hiện sự biến thiên của giá trị trong một thời điểm phản ánh xu thế của sự thay đổi.
Công thức (6) sẽ dùng để tính độ lệch chuẩn σ= σ2 (6)
Trong đó:
σ2: phương sai tính ở công thức (5)
Đơn vị σ là số gói tin
Bước 3: Xây dựng cơ chế phát hiện nút Bot:
Luận án đề xuất bất đẳng thức (7) mà nút thứ i được xem là có sự trao đổi dữ liệu bất thường (Bot) khi thỏa mãn điều kiện: Ni> µ + σ (7)
Trong đó:
Ni: Số gói tin mà nút i đó gửi hoặc nhận.
µ: giá trị trung bình tính ở công thức (4)
σ: độ lệch chuẩn tính ở công thức (6)
k: số tự nhiên lớn hơn 0
Lưu ý rằng tại một nút sẽ tính hai giá trị là số gói tin gửi và nhận từ đó cũng đưa ra hai độ lệch chuẩn khác nhau là độ lệch chuẩn cho số gói tin gửi và độ lệch chuẩn cho số gói tin nhận. Số gói tin của nút thứ i gửi hoặc nhận rất cao nếu so sánh với các nút còn lại. Đấy là điều bất thường và coi nút đấy như một nút Bot đang chuẩn bị tấn công DoS. 
Bảng 2.2 mô tả kết quả với từng ngưỡng khác nhau, thống kê, so sánh giữa số nút bị gán nhãn Bot so với số nút Bot thực tế dựa trên ngưỡng k khác nhau.
Bảng 2.2. Thống kê số nút bị gán nhãn Bot

Bị gán nhãn
Không bị gán nhãn
k
Là Bot
Không phải Bot
Tỉ lệ Báo động giả
Là Bot
Không phải Bot
1
30
83
73.45%
0
62887
2
30
16
34.78%
0
62954
3
30
5
14.29%
0
62965
4
22
4
15.38%
8
62966
Từ Bảng 2.2, đề xuất thiết lập tham số k trong bất đẳng thức (7) với ba mức cảnh báo khác nhau dựa trên Tỉ lệ “Báo động giả”. Kết quả là 3 bất đẳng thức (8), (9) và (10) như sau:
Mức I: bất thường k = 1, bất đẳng thức (8): Ni> µ+ σ (8)
Mức II: bất thường k = 2, bất đẳng thức (9): Ni> µ+ 2σ (9)
Mức III: bất thường k = 3, bất đẳng thức (10): Mức cách ly ngay lập tức nút bị gán nhãn “Bot tiềm tàng” Ni> µ+ 3σ (10)
Trong Bảng 2.2, với k = 4, đã có 8 nút Bots không được gán nhãn, không tuân theo chiến lược không Bỏ sót nút Bot mà tác giả đã đề cập ở phần trên. Vì vậy, giá trị tối đa của k là 3. Ngoài ra giá trị bất đẳng thức (10) cũng chính là giá trị nằm ngoài khoảng tin cậy trong phân bố Gauss trong toán học xác suất thống kê. Điều này cho thấy sự phù hợp của đề xuất cả về lý thuyết lẫn thực nghiệm. Thuật toán được chia làm 3 giai đoạn.
- Giai đoạn 1: Đếm số gói tin, chỉ đơn giản là tạo 2 mảng, mảng *arrsender dành cho số gói tin gửi đi, mảng *arrreceiver dành cho số gói tin mà nút đó nhận được. 
- Giai đoạn 2: Trong file client.c và malicious.c, sử dụng 1 vòng lặp for để tính giá trị trung bình, 1 vòng để tính phương sai. Sau đó dùng hàm sqrt() trong bộ thư viện . Cuối cùng, dùng if để kiểm tra từng nút một lấy từ file framer-802154.c. 
- Giai đoạn 3: Cấu hình giải pháp ngăn chặn Bots. Khởi tạo thêm 1 mảng nữa có độ dài bằng số nút trong giả lập ở file framer-802154.c để đánh dấu nút nào là nút bot. Các giá trị trong mảng được khởi tạo là 0. Trong quá trình mô phỏng, mảng này sẽ nhận tham chiếu từ thuật toán ở file client.c và malicious.c xem nút nào là Bot để đánh lại giá trị là 1. Sau đó, cài một điều kiện if-else trong file framer-802154.c để trong quá trình giao dịch, nếu phát hiện gói tin nút đó gửi tới, nó sẽ trả về FRAMER_FAILED.
Thí nghiệm mô phỏng giải pháp Overhearing
Kịch bản 1: Thí nghiệm mô phỏng trên Hệ điều hành Contiki
a)

b)

c)
Mô hình Lưới 4x4
a)

b)

c)
Mô hình Lưới 5x5
a)

b)

c)
Mô hình Lưới 6x6
Hình 2.4. Các kịch bản và các Mô hình mô phỏng
Kịch bản 2: Thí nghiệm với thiết bị thực tế Zolertia
Để phù hợp với các yêu cầu thông số bài toán đặt ra, tác giả lựa chọn các thiết bị Zolertia để tiến hành mô phỏng thí nghiệm với Contiki OS. Tác giả xây dựng một mạng WSN quy mô nhỏ trên thực tế với 4 thiết bị Zolertia trong thời gian 10 tiếng, tần suất giao dịch 10s/giao dịch.
(a)	 (b)
	Hình 2.5. Sơ đồ tương tác với thiết bị Zolertia trong thí nghiệm	
	Hình 2.6. Kết nối mô phỏng giải pháp với thiết bị thực	
(a) WSN không có nút Bots	(b) WSN có nút Bots
Hình 2.7: Sơ đồ kết nối các thiết bị mô phỏng
Kết quả mô phỏng tấn công, so sánh đánh giá
Bảng 2.4. Kết quả thông số thí nghiệm kịch bản thí nghiệm mô phỏng
Mô hình
Kịch bản
PDR (%)
Latency (ms/m)
Energy (mJ)
Lưới
4x4
TH0
95.13
674.92
139.05
TH1
94.98
796.55
148.46
TH2
13.59
56480.86
1204.05
TH3
91.34
1076.25
201.04
Lưới
5x5
TH0
97.03
618.76
127.66
TH1
96.31
642.23
132.27
TH2
15.83
51317.93
1185.78
TH3
93.69
983.27
195.13
Lưới
6x6
TH0
99.02
399.26
117.15
TH1
98.74
431.22
128.98
TH2
17.02
45208.63
1142.13
TH3
95.11
892.10
169.74
Tuy không thể ngăn chặn hoàn toàn cuộc tấn công DoS, nhưng giải pháp Overhearing đã giảm thiểu tác hại của cuộc tấn công. Kết quả này cho phép mở ra nhiều hướng nghiên cứu phát triển tiếp theo.
Mô phỏng mô hình thiết bị thực
Bảng 2.5. Kết quả thí nghiệm với các thiết bị thực tế
Kịch bản
PDR (%)
Latency (ms/m)
TH0
95.67
763.45
TH1
93.96
910.77
TH2
11.84
89453.14
TH3
91.02
1057.08
Bảng 2.5 đưa ra sự so sánh kết quả thí nghiệm với thiết bị thực tế ở cả ba kịch bản TH1: mạng hoạt động bình thường, TH 2: mạng bị tấn công DoS và TH3 mạng bị tấn công DoS nhưng đã cài Overhearing. Từ Bảng 2.3 rút ra một số nhận xét như sau về thí nghiệm kịch bản thực tế:
+ Thí nghiêm trên thiết bị thực tế đã tuân theo mô hình dự đoán rút ra từ thí nghiệm giả lập, như kịch bản TH2, khi mạng bị tấn công DoS có hiệu năng của mạng đã suy yếu đến mức không thể hoạt động bình thường ở TH3, khi các thiết bị Zolertia được cài Overhearing cải tiến thì mạng dù bị suy yếu dưới tác động của cuộc tấn công DoS nhưng vẫn duy trì hiệu năng ở mức hoạt động ổn định.
+ Hiệu năng trung bình của mạng với các thiết bị thực tế thấp hơn Hiệu năng trung bình của mạng giả lập do ảnh hưởng của các yếu tố ngoại cảnh. Dù vậy, hiệu năng mạng vẫn duy trì ở mức ổn định cho thấy giải pháp có tiềm năng triển khai trong thực tế với quy mô phức tạp hơn hoặc thương mại hóa.
Đánh giá giải pháp cải tiến cơ chế Overhearing
Hậu quả nghiêm trọng của một cuộc tấn công DOS lên IoT, cần thiết một giải pháp nhằm phát hiện sớm, hạn chế thiệt hại. Overhearing cải tiến đã chứng minh rằng nó có thể phát hiện nút Bot trong thời gian ngắn, việc cô lập nút Bot đã đem lại hiệu quả tích cực. Tuy vẫn còn hạn chế nhất định, cần cải tiến tích hợp thêm để đạt kết quả tốt hơn.
Các kết quả nghiên cứu của giải pháp được công bố trong các công trình [1], [3], [5], [7] tại các công trình công bố của luận án.
MÃ HOÁ NHẸ CHO CÁC THIẾT BỊ TÀI NGUYÊN YẾU
Thiết bị tài nguyên yếu
Trong bất kỳ giải pháp hoặc ứng dụng IoT nào, các thiết bị IoT là yếu tố quan trọng. Các thiết bị IoT này có thể được chia thành hai loại chính (Hình 3.1): nhiều tài nguyên như: máy chủ, máy tính cá nhân, máy tính bảng, v.v. và hạn chế về tài nguyên như: cảm biến, thẻ RFID, v.v... Loại thiết bị IoT thứ hai đang trở nên phổ biến hơn do chúng được sử dụng trong các ứng dụng khác nhau và sẽ xuất hiện nhiều trên thị trường, dẫn đến một tỷ lệ trao đổi dữ liệu lớn giữa chúng.
Hình 3.1. Hai danh mục chính của thiết bị IoT
Hình 3.3. Những đặc điểm thiết bị tài nguyên yếu trong hệ thống IoT
Bảng 3.1. Một số các thiết bị hạn chế công suất thấp phổ biến
Loại thiết bị
CPU
RAM
Flash/ROM
Crossbow TelosB
16-Bit MSP430
10 kbytes
48 kbytes
RedBee EconoTAG
32-Bit MC13224v
96 kbytes
128 kbytes
Atmel AVR Raven 
8-Bit ATMega1284P
16 kbytes
128 kbytes
Crossbow Mica2
8-Bit ATMega 128L
4 kbytes
128 kbytes
Zolertia Z1
16-bit RISC CPU16MHz
8 kbytes
92 kbytes
Hạn chế của IoT trước các cuộc tấn công chủ động
Thứ nhất, các thành phần cảm biến trong mạng IoT không được mã hóa bảo vệ, và hầu hết đều sử dụng địa chỉ MAC làm định danh. Sử dụng kết nối không dây, trong môi trường mở, dễ dàng bị thu thập.
Thứ hai, dữ liệu truyền trong các nút cảm biến không được bảo mật, từ đó, kẻ tấn công có thể chặn bắt các gói tin và phân tích ngược dữ liệu và từ đó phục vụ cho các cuộc tấn công liên quan đến tính sẵn sàng như tấn công DOS. 
Thứ ba, các nhà sản xuất và quản trị mạng IoT chưa xây dựng chính sách và tiêu chuẩn bảo mật phù hợp với đặc thù mạng.
Hình 3.2. Thách thức an toàn bảo mật IoT với các thiết bị tài nguyên yếu
Tổng quan về giải pháp cho các thiết bị tài nguyên yếu
Giao thức bảo mật nhẹ Lightweight cho IoT
Mật mã nhẹ là mật mã được dùng cho mục đích bảo mật, xác thực, nhận dạng và trao đổi khóa; phù hợp cài đặt cho những môi trường tài nguyên hạn chế. Với các thiết bị có tài nguyên hạn chế thì các thuật toán mật mã thông thường là quá lớn, quá chậm và quá tốn năng lượng. Các thuật toán mật mã nhẹ khắc phục được những nhược điểm này.
Các yêu cầu thiết kế và mật mã hạng nhẹ cần
Về độ an toàn, mục tiêu xây dựng các hệ mã hạng nhẹ là thiết kế một hệ mật không quá yếu (và không với mục đích thay thế các thuật toán mã truyền thống khác), nhưng phải đủ an toàn (tất nhiên không thể kháng lại được các đối phương có đủ mọi điều kiện), chi phí (cài đặt, sản xuất) thấp và một yêu cầu quan trọng đối với các thiết bị kiểu này là tính gọn nhẹ “on-the-fly”. Tóm lại, cần xây dựng một hệ mật không phải tốt nhất, mà phải cân bằng giữa giá thành, hiệu suất và độ an toàn. Về hiệu quả trong cài đặt, thường được đánh giá qua các độ đo sau: diện tích bề mặt (Area), Số chu kỳ xung nhịp (cycles), Thời gian, Thông lượng (throughput), Nguồn (power), Năng lượng (energy), Dòng điện (current). Tính hiệu quả là tỷ lệ thông lượng với diện tích, được dùng làm độ đo cho tính hiệu quả phần cứng. Mã khối hạng nhẹ là một nhóm thuộc mật mã nhẹ sử dụng trong an toàn thông tin, ở đó thuật toán mã hóa sử dụng đầu vào là các khối B-bit và khóa là K-bit.
Triển khai giải pháp DTLS trên nền tảng Om2M
Mô hình bảo mật cho IoT dựa trên DTLS
Hình 3.5. Kiến trúc bảo mật cho hệ thống IoT theo chuẩn oneM2M
DTLS không thiết kế cho các thiết bị IoT hạn chế, mặc dù hiện nay cũng có một số công trình nghiên cứu đề xuất các cơ chế tinh chỉnh và tối ưu DTLS cho các thiết bị IoT nhưng việc triển khai DTLS trên các thiết bị trong thực tế vẫn gặp rất nhiều khó khăn, đặc biệt là khi tích hợp DTLS với các giao thức khác như CoAP, 6LoWPAN.
Hình 3.6. Xây dựng Plugin để làm việc với giao thức DTLS
Trong phần MN của OM2M tacs giar xây dựng một Plugin để làm việc với giao thức DTLS. Module DTLS-Client dùng để giao tiếp với DTLS-Server với kênh truyền bảo mật DTLS. DTLS-Client mở một TCP socket dùng để đưa dữ liệu giao tiếp với DTLS-Server ra môi trường bên ngoài thông qua chuẩn Socket, module TCP Socket làm cầu nối giữa OM2M với DTLS, giao tiếp với TCP Socket Server được mở trên DTLS-Server giúp việc kết nối trở nên dễ dàng và linh hoạt. Dữ liệu sau khi lấy từ DTLS-Client rồi chuyển sang TCP Socket sẽ được chuẩn hóa theo cấu trúc đã được định nghĩa sẵn tại Data model.
Thử nghiệm và đánh giá mô hình an ninh DTLS
Hình 3.7. Các thành phần trong hệ thống thử nghiệm
Bảng 3.5. Quá trình bắt tay của DTLS tại thiết bị
Quy trình
T.Gian (ms)
Quy trình
T.Gian(ms)
(1) HelloVerifyRequest
2
(5) CertificateRequest*
No
(2) ServerHello
2
(6) ServerHelloDone
2
(3) Certificate*
3
(7) ChangeCipherSpec
9.800
(4) ServerKeyExchange*
20.050
(8) Finished
2
* Tùy chọn (có thể không cần tích hợp)
Bảng 3.6. Bộ nhớ thiết bị sử dụng DTLS với tinyDTLS và tinyECC

Thiết bị bình thường
Thiết bị với DTLS
ROM
48, 8 KB
76, 8 KB
RAM
11, 6 KB
12, 8 KB
Thực hiện hơn 1.000 phép đo đạc, trong đó trong một lần sẽ có 5 truy vấn được gửi đi đồng thời với 5 thiết bị khác nhau trên cùng một MN. Tỷ lệ các truy vấn thực hiện thành công trả về kết quả là 100%. 
Hình 3.5. Kích thước gói tin khi mã hóa DTLS
Khi sử dụng DTLS thì nội dung dữ liệu y tế khi truyền trên đường truyền sẽ được mã hóa bảo vệ dữ liệu và không bị sửa đổi. 
Hình 3.6. Kết quả giám sát thông tin trên môi trường sử dụng DTLS
Với kịch bản không sử dụng DTLS mà chỉ sử dụng thuần UDP thì qua wireshark ta có thể thấy rằng dữ liệu dễ dàng đọc hiểu và khai thác được, hơn nữa vì không có cơ chế bảo vệ nên sẽ dễ dàng bị giả mạo. 
Đánh giá giải pháp cải tiến DTLS tích hợp vào IoT
Mặc dù đạt được kết quả khả quan, vẫn tồn tại một số hạn chế như chưa thể xây dựng được CoAP trên tầng ứng dụng. DTLS chỉ phù hợp với các thiết bị có cấu hình tương tự như REMote. Không thể tích hợp trên mạch khác như Zolertia Z1 hoặc Micaz (vi xử lý MSP430 8-16 MHz, 96KB ROM, 8KB RAM). Thời gian kết nối truyền nhận dữ liệu vẫn có một độ trễ nhất định. Bên cạnh đó, chi phí của các thiết bị phần cứng đáp ứng được yêu cầu của DTLS cũng tạo ra rào cản trong việc triển khai hệ thống một cách rộng rãi. Cần tiếp tục nghiên cứu các giải pháp để giải quyết các tình huống xảy ra khi giản lược các bước, giảm độ dài khoá ảnh hưởng đến nguy cơ tấn công khai phá như vét cạn.
DTLS cải tiến đã phần nào hạn chế được các nguy cơ tấn công từ trung gian như tấn công nghe lén, giải mạo thông điệp. Góp phần tăng cường đảm bảo hệ thống an toàn, an ninh thông tin trong mạng IoT.
Kết quả nghiên cứu được công bố tại các công trình: [4][6].
Giải pháp cải tiến giao thức CurveCP trên WSN
CurveCP là một giao thức bảo mật kết hợp mã hóa Elliptic Curve, với sự gọn nhẹ, linh hoạt, độ an toàn tương đối tốt thông qua các cơ chế mã hóa, phù hợp với môi trường IoT. Giải pháp này ứng ựng CurveCp cải tiến để hỗ trợ tăng cường an toàn bảo mật IoT trước các tấn công trung gian, nghe lén, chặn bắt thông tin, sửa đổi, giả mạo và phát lại thông điệp.
Hình 3.7. Vị trí cài đặt của Giao thức CurveCP
Hình 3.8. Cơ chế trao đổi khóa trong giao thức CurveCP.
Cải tiến diễn ra trên cả ba loại thông điệp bao gồm Thông điệp Hello, Thông điệp Cookies và thông điệp Initiate. Cụ thể, tất cả 8 khóa gồm C(P), C(S), C’(P), C’(S) ở Client và S(P), S(S), S’(P) S’(S) ở Sever đều có độ dài là 32 bit, được giảm xuống 50% còn 16 bit.
Kết quả mô phỏng với giải pháp cải tiến CurveCP
Bảng 3.6. Kết quả đo thông số mạng IoT với CurveCP
Loại mạng
PDR (%)
Latency (ms)
Energy (mJ)
Không cài CurveCP
98.67
543.98
119.21
CurveCP không cải tiến
92.13
893.24
287.90
CurveCP cải tiến
95.04
700.13
219.81
CurveCP cải tiến có thể được triển khai trên mạng IoT và đảm bảo tiêu thụ năng lượng không ảnh hưởng xấu đến hoạt động của mạng, đảm bảo được tính bí mật của thông tin sau khi đã mã hó