DTLS Overhearing
Vị trí trong
IoT Lớp truyền thơng (liên quan đến giao thức) Lớp cảm biến (WSN) Mục tiêu bảo vệ Tính bí mật (Confidentiality): Chống nghe lén Tính tốn vẹn (Integrity): Chống giả mạo Tính sẵn sàng (Availability): Chống tấn cơng DoS
Nội dung Cơ chế mã hĩa đối xứng và bất đối xứng
Cơ chế hàm băm dữ liệu Cơ chế phục hồi dữ liệu ECC
Cơ chế giám sát các nút xung quanh
Cơ chế cách ly nút bị lây nhiễm dựa trên thuật tốn “Vượt giá trị trung bình” Vị trí mã
nguồn
Thư mục “tiny-dtls” trong thư mục “app”
Trong file framer-802154.c của “core/net/mac”
Phạm vi ảnh hưởng
Những mơ phỏng cĩ đường dẫn tới thư mục “app”
Tất cả mơ phỏng trong Contiki cĩ nút mạng sử dụng chuẩn IEEE 802.15.4
Với việc được trang bị nhiều cơ chế thuật tốn khác nhau, giao thức DTLS là một giao thức bảo mật mạnh và cĩ thể được coi là hiệu quả khi cĩ khả năng bảo vệ cả ba tính chất cơ bản cảu an ninh và an tồn thơng tin. Tuy nhiên, giải pháp này cĩ tồn tại một số bất cập khi triển khai trên mơ hình mạng cảm biến khơng dây. Thứ nhất, giao thức DTLS được triển khai trên mạng WSN cĩ tài nguyên bị giới hạn, tuy nhiên giao thức này lại cĩ nhiều cơ chế mã hĩa phức tạp, tiêu tốn nhiều tài nguyên
nên chiếm tài nguyên mạng WSN, ảnh hưởng tiêu cực đến hiệu năng mạng, thậm chí làm mạng WSN bị cạn kiệt tài nguyên. Cụ thể, Giao thức DTLS cĩ nhiều cơ chế mã hĩa phức tạp, tiêu tốn nhiều tài nguyên, khĩ khăn khi thực thi trên mơi trường mơ phỏng mạng IoT thơng thường, cả khi chưa cĩ Overhearing, chẳng hạn như nút
Tmote Sky trên MSP430 cĩ bộ nhớ RAM là 10 KB và bộ nhớ Flash là 48 KB khơng
thực hiện được. Thứ hai, giao thức DTLS về lý thuyết cĩ thể coi là giải pháp, nhưng thực tế do cơ chế phịng chống tấn cơng DoS quá yếu, khơng đáp ứng được yêu cầu hiện nay trước các cuộc tấn cơng DoS cĩ thủ đoạn tinh vi. Khơng những vậy, cơ chế DoS Countermeasures cũng tiêu thụ năng lượng và khiến cho mạng WSN sử dụng giao thức DTLS lại càng bị tiêu hao tài nguyên.
Vì thế, cần cĩ sự thay đổi để giảm tiêu thụ năng lượng, giúp hệ thống vận hành tốt hơn, tuy nhiên, sự thay đổi này cần phải đảm bảo khơng bị mất đi những ưu điểm mà vẫn bảo vệ an tồn dữ liệu và sự ổn định trong mạng IoT. DTLS tập trung vào tính bảo mật và tính xác thực, cơ chế phịng chống tấn cơng DoS được loại bỏ để tiết kiệm năng lượng. Từ đĩ, giải pháp tiêu thụ năng lượng ít hơn và cĩ khả năng tích hợp các cơ chế phịng chống tấn cơng DoS mạnh hơn.
Các cải tiến được thực hiện gồm các nội dung sau:
Giảm độ dài khĩa thuật tốn AES: Thuật tốn mã hĩa AES [93] là một loại
mã hĩa cĩ độ phức tạp cao, dựa vào độ phức tạp thuật tốn để nâng cao sự an tồn. Việc giảm độ dài khĩa AES khơng làm giảm độ phức tạp của thuật tốn nhưng sẽ làm giảm thời gian tính tốn, từ đĩ làm giảm độ trễ của mạng IoT. Trong “tiny-dtls” thì độ dài khĩa là 16 bits sẽ được xử lý giảm xuống cịn 8 bits.
Giảm độ dài khĩa thuật tốn băm SHA: Giảm độ dài khĩa SHA cũng làm
giảm thời gian tính tốn, giảm độ trễ của mạng, tuy nhiên độ dài khĩa càng thấp thì nguy cơ nhiều loại dữ liệu bị mã hĩa giống nhau, tăng nguy cơ giả mạo dữ liệu [94], tuy nhiên dữ liệu cũng khơng qúa lớn để dễ tạo gây trùng lặp. Trong “tiny-dtls” thì độ dài khĩa là 32 bits, nhưng trong thí nghiệm thì độ dài khĩa sẽ được giảm xuống cịn 16 bits.
Việc giảm độ dài khĩa cĩ phần nào ảnh hưởng đến độ an tồn các thuật tốn, tuy nhiên trên cơ sở thiết lập tích hợp cơ chế an tồn bảo mật nhiều lớp với giới hạn thiết bị tài ngun hạn chế đã phân tích trong phần trước thì sự cân đối giữa hiệu
năng mạng, độ an tồn các thiết bị IoT này là phù hợp.
Bỏ qua cơ chế phịng chống tấn cơng DoS trong DTLS: Trong cơ chế
phịng chống tấn cơng DoS (DoS Countermeasures) ở DTLS, bản tin
HelloVerifyRequest máy chủ và bản tin ClientHello máy khách sử dụng bộ nhớ đệm khơng trạng thái để tạo cơ chế xác thực các bản tin xem cĩ phải bản tin rác khơng, từ đĩ xác định các cuộc tấn cơng DoS. Với cơ chế Overhearing thì cơ chế DoS Countermeasures là khơng cần thiết và cĩ thể tăng tiêu thụ bộ nhớ, thậm chí cĩ thể gây tắc nghẽn nếu cĩ nhiều nút cùng tiến hành quá trình bắt tay. Vì vậy, luận án lược bỏ cơ chế DoS Countermeasures trong DTLS khi kết hợp cài đặt cùng Overhearing.
Với ba thiết lập điều chỉnh này, mạng sau khi tích hợp DTLS sẽ được giảm tải tương đối nhưng vẫn đảm bảo độ an tồn thơng tin và hồn tồn cĩ thể tích hợp thêm cơ chế Overhearing thành một giải pháp tổng thể.
a. Thiết kế và cài đặt mơ phỏng, thử nghiệm
Thiết kế thí nghiệm mơ hình mơ phỏng
Như đã đề cập, mục tiêu của nghiên cứu là cho thấy tính khả thi, hiệu quả và phù hợp trong việc kết hợp giữa DTLS với Overhearing trên cùng một hệ thống nhằm xây dựng cấu trúc an ninh đa lớp cho mạng IoT, tiến hành mơ phỏng thử nghiệm trên Contiki-OS. “Tiny-dtls” phù hợp với hầu hết mơ phỏng IoT trong Contiki-OS, cơ chế mã hĩa độc lập với Overhearing, tuy nhiên cần xem xét thêm liệu DTLS cĩ cản trở hoạt động của Overhearing trước cuộc tấn cơng DoS bằng Botnet và UDP Flood hay khơng. Ngồi ra, một mục đích khác là so sánh giữa giải pháp an ninh kết hợp với DTLS đã cải tiến và DTLS nguyên bản để chứng tỏ sự cần thiết của những cải tiến. Để thực hiện được mục tiêu như vậy, chúng tơi sẽ xây dựng 8 kịch bản mơ phỏng, 4 kịch bản đầu khi WSN hoạt động bình thường cịn 4 kịch bản sau hoạt động khi WSN bị tấn cơng DoS.
Kịch bản 1 (KB 1): Mạng hoạt động bình thường, khơng cài Overhearing,
khơng cài DTLS.
Kịch bản 2 (KB 2): Mạng hoạt động bình thường, cài Overhearing, khơng
Kịch bản 3 (KB 3): Mạng hoạt động bình thường, cài Overhearing, cài
DTLS nguyên bản.
Kịch bản 4 (KB 4): Mạng hoạt động bình thường, cài Overhearing, cài
DTLS cải tiến.
Kịch bản 5 (KB 5): Mạng hoạt động khi bị tấn cơng DoS, khơng cài
Overhearing, khơng cài DTLS.
Kịch bản 6 (KB 6): Mạng hoạt động khi bị tấn cơng DoS, cài Overhearing,
khơng cài DTLS.
Kịch bản 7 (KB 7): Mạng hoạt động khi bị tấn cơng DoS, cài Overhearing
& DTLS.
Kịch bản 8 (KB 8): Mạng hoạt động khi bị tấn cơng DoS, cài Overhearing,
cài DTLS nguyên bản.
Thời gian là 50 phút mỗi kịch bản. Mạng IoT dùng trong thí nghiệm cĩ dạng lưới hình vuơng, một dạng khá phổ biến trong thực tế vì mạng lưới này cho phép đa dạng trong định tuyến.
(a) Hoạt động bình thường (b) Tấn cơng DoS
Hình 4.3. Kiến trúc mạng IoT trong các kịch bản mơ phỏng
Trong Hình 4.3a, nút nền đen chữ trắng là nút Server, nút nền trắng chữ đen là nút Client. Trong điều kiện bình thường các nút Client sẽ gửi các bản tin định kỳ cho nút Server. Trong tấn cơng DoS ở Hình 4.3b, cĩ 3 nút bị nhiễm mã độc thành nút Bot là các nút nền kẻ chéo, chữ đen. Các nút này thực hiện tấn cơng UDP Flood bằng cách gửi nhiều gĩi tin cho nút Server và chiếm tài nguyên của nút này. Sự phân bố các nút Bot ở các mức xa gần khác nhau cũng như vị trí khác nhau của cây
định tuyến mạng so với nút Server, đảm bảo sự đa dạng cũng như sự bao trùm trong tấn cơng DoS.
4.1.3. Kết quả thí nghiệm mơ phỏng, so sánh đánh giá
a. Kiểm tra, so sánh gĩi tin và đánh giá
So sánh kịch bản cài DTLS và khơng cài DTLS
Để cĩ thể kiểm tra hoạt động của giao thức DTLS, ta bắt buộc phải bắt các gĩi tin trao đổi để phân tích nội dung và đánh giá độ an tồn. Mục đích của việc bắt các gĩi tin cĩ theo dõi loại gĩi tin và nhận biết các gĩi tin đặc thù trong các giao thức bảo mật. Chẳng hạn, mạng cĩ cài DTLS sẽ cĩ một số gĩi tin mà mạng khơng cài DTLS khơng thể cĩ vì các gĩi tin này cĩ nhiệm vụ thực hiện các chức năng chuyên biệt như mã hĩa, bắt tay liên kết. Một trong số đĩ là các gĩi tin bản tin MDNS (Multicast Domain Name System), cĩ chức năng thực hiện quá trình bắt tay để trao đổi khĩa giữa các máy chủ tên miền với nhau trong giao thức DTLS, các mạng bình thường, khơng cĩ cơ chế bảo mật mã hĩa thì sẽ khơng cĩ loại bản tin này [89].
Thí nghiệm mơ phỏng cũng sử dụng Wireshark để bắt các gĩi tin và phân tích. Các gĩi tin được phân tích là các bản tin dữ liệu của các nút mạng và hai mạng sẽ được so sánh với nhau là mạng cĩ cài DTLS (nguyên bản) là Kịch bản KB3 và mạng khơng cĩ cài DTLS là Kịch bản KB2. Lý do chọn hai kịch bản này là vì cả hai Kịch bản này đều khơng chịu sự tác động của tấn cơng DoS cũng như đều đã cài Overhearing, với DTLS nguyên bản, KB3 sẽ biểu thị phiên bản đầy đủ nhất của DTLS. Mạng cĩ các bản tin MDNS là mạng đã cài đặt thành cơng giao thức DTLS. Kết quả được trình bày trong Hình 4.4 với các gĩi tin đã được sắp xếp theo thứ tự tăng dần trong bảng chữ cái Alphabet, ở trường loại bản tin (Protocol).
(a) Mạng cĩ cài giao thức DTLS
(b) Mạng khơng cài giao thức DTLS
Hình 4.4. Sự xuất hiện của các bản tin MDNS trong mạng cài DTLS
Ta cĩ thể thấy sự xuất hiện của các bản tin MDNS trong mạng cĩ cài DTLS (màu nâu đỏ). Như vậy, quá trình mã hĩa được thiết lập và giao thức DTLS cĩ thể chạy ổn định.
b. Kiểm tra, đánh giá hiệu năng mạng
Trên phạm vị tồn bộ WSN, tác giả sử dụng cả ba thơng số đo đạc đã đề cập và xây dựng ở Chương 2 bao gồm PDR, độ trễ và năng lượng tiêu thụ, giá trị từng thơng số sẽ lấy trung bình của tất cả các nút mạng, khơng phân biệt vị trí. Nút Tmote Sky cĩ khả năng chịu được cơng suất tiêu thụ là 12.6 mW [43] trong 1 giờ, tức là 1.05 mW trong 50 phút thí nghiệm. Năng lượng quy đổi tương đương là 315 mJ [46]. Với thiết bị Tmote Sky thì các hằng số tính năng lượng từ Cơng thức (3) ở
Phần 2 sẽ cĩ giá trị như sau dựa trên thơng số kỹ thuật của Moteiv[55]: Et = 19.5; Er
= 21.8; Eo = 1.8; EI = 0.545 và τ =
Kết quả thơng số đo đạc
Bảng 4.2 sẽ trình bày kết quả thí nghiệm với từng kịch bản từ KB1 tới KB8. Lưu ý, các giá trị trong kết quả này là các giá trị trung bình của các nút tồn mạng IoT với từng thơng số.