Khi sử dụng DTLS thì nội dung dữ liệu IoT y tế khi truyền trên đường truyền sẽ được mã hĩa giúp cho việc bảo vệ dữ liệu khơng bị lộ thơng tin và khơng bị sửa đổi (xem thêm tại Phụ lục Hình 8 (PL)).
Nội dung dữ liệu đã được mã hĩa thành 22 bytes và dữ liệu sau khi được mã hĩa sẽ khơng thể đọc hiểu được. Phương thức mã hĩa sử dụng là TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (được mơ tả trong Phụ lục Hình
9 (PL)).
Với kịch bản khơng sử dụng DTLS mà chỉ sử dụng thuần UDP thì qua các thiết bị chặn bắt gĩi tin như wireshark ta cĩ thể thấy rằng dữ liệu khơng được mã hĩa 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. Ngồi ra ta cĩ thể thấy là khi khơng mã hĩa thì kích thước payload của phần dữ liệu là 6 bytes. Mặc dù đạt được kết quả khả quan, mơ hình đề xuất vẫn tồn tại một số hạn chế. Thứ nhất, nĩ chưa thể xây dựng được CoAP trên tầng ứng dụng. CoAP khi tích hợp với DTLS thường dẫn đến tràn bộ nhớ RAM, dù đã được triển khai trên thiết bị REMote (32KB RAM). Do đĩ khơng thể đảm bảo được đường truyền bảo mật thơng suốt end-to-end giữa người dùng và thiết bị cảm biến đầu cuối. Thứ hai, DTLS chỉ thực sự phù hợp với các thiết bị cĩ cấu hình tương tự như REMote [75]. 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).
Phiên bản mơ phỏng giao thức DTLS sử dụng trên Contiki-OS là “tiny-dtls” được tích hợp trong phạm vi quản lý của file “project-conf.IoT” thay vì tồn bộ trong Contiki-OS.
Để cĩ thể phịng chống hiệu quả các cuộc tấn cơng trên, giao thức DTLS. Một thơng điệp được mã hĩa bằng khĩa cơng khai và thuật tốn mã hĩa cĩ thể được giải mã bằng thuật tốn giải mã và khĩa riêng phù hợp của khĩa cơng khai tương ứng. Ưu điểm của mã hĩa bất đối xứng cung cấp bảo mật dữ liệu nhiều hơn. Mặt khác, sự tham gia của hai khĩa làm cho việc mã hĩa bất đối xứng tốn thời gian và phức tạp hơn [96]. Giao thức DTLS sử dụng cả hai giải pháp mã hĩa trên. Về mã hĩa đối xứng, DTLS sử dụng mã hĩa đối xứng AES cịn về mã hĩa bất đối xứng, DTLS được trang bị thuật tốn Differ – Helman [97]. Ngồi hai thuật tốn mã hĩa cơ bản ra, giao thức DTLS cịn cĩ cơ chế băm dữ liệu để phục vụ xác thực người dùng với thuật tốn băm SHA và cơ chế phục hồi dữ liệu EEC. Ngồi ra, giao thức DTLS cũng được trang bị cơ chế phịng chống tấn cơng DoS được gọi là DoS Countermeasures. Tuy nhiên, cơ chế này hiệu quả khơng cao và khơng thể chống được tấn cơng phức tạp và tinh vi như tấn cơng Botnet.
3.3.4.Kết luận
Kết quả triển khai và thử nghiệm thành cơng DTLS với sự điều chỉnh hoạt động trên cho thấy, mơ hình đề xuất với những thay đổi đưa ra của luận án là phù hợp với mơi trường IoT thiết bị tài nguyên yế, giải pháp cho thấy cĩ thể triển khai trên cơ sở lý thuyết cũng như trong điều kiện thực tế.
Những kết quả đạt được gồm việc điều chỉnh giản lược các bước trong tiến trình thực hiện của DTLS, giảm độ dài khĩa, thay đổi phương thức xác thực nhằm cân bằng các yếu tố hiệu năng và an tồn mạng. Chấp nhận giảm mức độ an tồn so với nguyên bản giao thức, nhưng bù lại cĩ thể nâng cao được hiệu năng và quan trọng là áp dụng được những chức năng cơ bản của giao thức DLTS vào các thiết bị tài nguyên yếu trong mạng IoT. Với các dịch vụ ưu tiên về tính sẵn sàng, cần đảm bảo hiệu năng và mức độ an tồn cơ bản thì giải pháp là hiệu quả, đáp ứng được nhu cầu trong bối cảnh phạm vi nghiên cứu.
Trong thực tế mơ hình triển khai, giải pháp DTLS thơng thường khơng thể cài đặt và thực hiện được khi khơng cĩ các điều kiện cải tiến bổ sung cài đặt theo đề
xuất của luận án. Trong quá trình mơ phỏng, tác giả và cộng sự đã nhiều ngày liên tục thử nghiệm, kết quả là hệ thống khơng thể thực hiện được giao dịch nào khi cài đặt DTLS nguyên bản, do nhu cầu tính tốn, yêu cầu tài nguyên của giao thức DTLS là khá lớn, trong phạm vi nghiên cứu của luận án, với các thiết bị IoT tài nguyên yếu thì giải pháp DTLS mặc định khơng khả thi dù thực hiện trên mơ hình thực tế hay trong cấu hình mơ phỏng.
Các kết quả thử nghiệm chỉ ra rằng tuy cĩ thể triển khai giao thức DTLS trên các thiết bị IoT nhưng vẫn cịn tồn tại rất nhiều hạn chế như khơng thể tích hợp đồng thời giao thức tầng ứng dụng (CoAP), 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.
Kết quả của giải pháp được trình bày trong “Hội nghị khoa học quốc gia Nghiên cứu cơ bản và ứng dụng Cơng nghệ thơng tin lần thứ 11 (FAIR 2018)”, và bài báo [4] tại tuyển tập các cơng trình cơng bố của luận án.
3.4. Triển khai CurveCP trên mạng WSN 3.4.1.Tổng quan về CurveCP
Như đã trình bày ở trên, các cuộc tấn cơng nghe lén vào tính bảo mật và các cuộc tấn cơng giả mạo vào tính tồn vẹn của thơng tin gây ra nhiều thiệt hại cho hệ thống mạng IoT về cả tài chính lẫn niềm tin. Trước tình hình đĩ, các nhà khoa học đã thiết kế các giao thức bảo mật dành riêng cho các thành phần trong mạng IoT và một trong số đĩ là giao thức mã hĩa CurveCP. Giao thức CurveCP đã được giới thiệu vào năm 2011 [30] và đã qua nhiều lần cải tiến và hồn thiện về mặt lý thuyết. Mặc dù vậy, chưa cĩ một nghiên cứu nào cĩ thể cài đặt hồn chỉnh giao thức này và thí nghiệm với một mơ hình mạng cĩ thật trong thực tế. Về mặt lý thuyết, việc triển khai một mơ hình phụ trợ đặc biệt là các mơ hình bảo mật cĩ cơ chế mã hĩa luơn luơn tạo ra sự tiêu thụ rất nhiều tài nguyên, ảnh hưởng đến hoạt động mạng IoT và thậm chí cĩ thể làm ngưng trệ tồn mạng. Chính vì lẽ đĩ, phần nghiên cứu này tập trung vào điều chỉnh và cài đặt mã nguồn của giao thức CurveCP trên mơ phỏng hoạt động IoT ở hệ điều hành Contiki OS để so sánh hiệu năng mạng đã cài đặt giao thức CurveCP với mạng chưa cài đặt giao thức CurveCP và từ đĩ đánh giá tính khả
thi của việc cài đặt CurveCP trên mạng IoT.
CurveCP là một giao thức bảo mật kết hợp mã hĩa, sử dụng mật mã Elliptic Curve Cryptography, với sự gọn nhẹ, linh hoạt, độ an tồ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. Vị trí cài đặt của giao thức CurveCP được mơ tả như Trong Hình 3.6.