Thời gian Thời gian (ms)
(1) HelloVerifyRequest 2 (5) CertificateRequest* (0 thực hiện)
(2) ServerHello 2 (6) ServerHelloDone 2
(3) Certificate* 3 (7) ChangeCipherSpec 9.800
(4) ServerKeyExchange* 20.050 (8) Finished 2
Bảng 3.5 đưa ra các giá trị đo liên quan bộ nhớ ROM và RAM trong trường hợp truyền thơng điệp với UDP thơng thường và trường hợp cĩ tích hợp DTLS. Rõ ràng, tích hợp DTLS khiến bộ nhớ ROM tăng khoảng 28 KB và bộ nhớ RAM tăng khoảng 1.2 KB. Mức tăng này là chấp nhận được với thiết bị như REMote (512 KB ROM và 32KB RAM).
Bảng 3.5. Bộ nhớ thiết bị sử dụng DTLS với hai thư viện 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
Những phân tích ở trên là cơ sở để thiết lập các thơng số cài đặt và cấu hình cần thiết cho hệ thống theo dõi sức khỏe của bệnh nhân bằng cảm biến IoT y tế. Một trong những thơng số quan trọng nhất chính là thời gian duy trì phiên kết nối. Thời gian này hồn tồn phụ thuộc vào thiết bị cảm biến cần sử dụng. Ví dụ, thời gian đo nhịp thở trung bình khoảng 5 phút (trong đĩ 3 phút là khoảng thời gian cần thiết để thiết bị hoạt động ở trạng thái ổn định). Đo huyết áp, phế dung, lượng đường trong máu cần 2 phút, trong khi thời gian để đo nhiệt độ cơ thể là khoảng 1 phút. Nếu so sánh với quá trình đo đạc tại thiết bị cảm biến, thì thời gian 30 giây thực hiện bắt tay (DTLS handshake) là cĩ thể chấp nhận được. Thí nghiệm cũng tiến hành 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 được thực hiện thành cơng và trả về kết quả là 100%.
90
Trong nguyên bản của cấu trúc DTLS, tác giả luận án cùng cộng sự đã nhiều lần thực hiện trong mơi trường thực tế cũng như mơ hình giả lập trên Contiki trong một thời gian dài, kết quả cho thấy, mạng IoT thiết bị tài nguyên yếu khơng thể hoạt động được, khơng cĩ một giao dịch nào cĩ thể thực hiện được trong suốt quá trình thử nghiệm, điều đĩ cho thấy, giao thức DTLS là quá nặng và chiếm dụng quá nhiều tài nguyên trong các thiết bị tài nguyên yếu dẫn đến phương án tích hợp nguyên bản thơng thường là bất khả thi.
Hình 3.5. Các pha làm việc của DTLS
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
91
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
92
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 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
93
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.
Hình 3.6. Vị trí cài đặt của Giao thức CurveCP
Từ Hình 3.6, dễ dàng nhận ra giao thức CurveCP được chia làm hai phiên bản là CurveCP Server dành cho một nút Sink cĩ vai trị tập hợp dữ liệu và CurveCP Client dành cho các nút Sensor. Giao thức CurveCP kiểm sốt đường truyền của mỗi nút mạng IoT, mọi dữ liệu đi ra và vào các nút mạng này đều được CurveCP bắt chặn gĩi tin để tiến hành mã hĩa – giải mã trước khi được xử lý bởi nút mạng.
a. Cơ chế mã hĩa trong CurveCP
Giao thức CurveCP tuân theo cơ chế mã hĩa dịng (Stream-Cipher), sử dụng trên tầng Ứng dụng của mạng IoT. CurveCP cĩ 4 đặc điểm quan trọng gồm những đặc điểm sau:
- Thứ nhất, giao thức CurveCP dùng cho cơ chế Client – Server và chỉ tập trung vào bảo vệ máy chủ Server.
94
- Thứ hai, giao thức CurveCP sử dụng cơ chế khĩa bất đối xứng bao gồm khĩa cơng khai (Public key) và khĩa mật (Secret key). Cơ chế này cho phép kết hợp mã hĩa với xác thực dữ liệu thơng qua một Hộp mã hĩa (Cryptography Box) mà chỉ chức năng mã hĩa hoặc giải mã bằng các khĩa riêng biệt. Chính vì thế, ưu điểm của giao thức mã hĩa CurveCP là kết hợp giữa xác thực và mã hĩa thơng qua hàm Box nên chi phí tính tốn thấp hơn.
- Thứ ba, giao thức CurveCP phân phối khĩa theo cơ chế khĩa phiên – khĩa chính. Khĩa chính sử dụng cĩ tần suất thay đổi rất thấp nhưng yêu cầu bảo mật cao cịn khĩa phiên thì được ánh xạ từ khĩa chính, thời gian sử dụng ngắn và được sử dụng thường xuyên nên khơng cĩ tính bảo mật cao như khĩa chính. Việc điều phối hoạt động giữa khĩa chính và khĩa phiên do một đoạn mã Thơng báo điều phối (Nonce) quyết định. Trong việc trao đổi dữ liệu, chỉ cĩ khĩa phiên cơng khai, định danh và Nonce là nằm ở bản rõ, cịn tất cả những thơng số cịn lại đều phải được mã hĩa thơng qua các khĩa phiên cơng khai của cả Server và Client. Ngồi ra, điều đặc biệt của Hộp mã hĩa trong CurveCP cĩ thể sử dụng khĩa phiên để mà hĩa và khĩa chính để giải mã hoặc ngược lại và phải đi kèm với Nonce.
- Cuối cùng, giao thức CurveCP sử dụng bộ đệm (Cookies) mà chỉ cĩ Server cĩ thể đọc được và Server cĩ sở hữu một khĩa đối xứng được gọi là khĩa siêu mật để mã hĩa và giải mã Cookies đĩ.
Trong cơ chế mã hĩa ở Giao thức CurveCP, Giao thức trao đổi khĩa là nhân tố quan trọng làm lên thành cơng của bộ mã hĩa này. Giao thức này được chia làm 2 giai đoạn: Khởi tạo và Truyền tin. Hình 3.7 mơ tả tổng thể giao thức trao đổi khĩa mã hĩa trong CurveCP.
Hình 3.7. Cơ chế trao đổi khĩa trong giao thức CurveCP.
95
như sau: Client sở hữu khĩa chính cơng khai C(P), khĩa chính mật C(S), khĩa phiên cơng khai C’(P) và khĩa phiên mật C’(S); Server sở hữu khĩa chính cơng khai S(P), khĩa chính mật S(S), khĩa phiên cơng khai S’(P) và khĩa phiên mật S’(S); Nonce sẽ được ký hiện là N(x) trong đĩ x là khĩa cần xác thực; B(x) là bản mật của bản rõ x được mã hĩa đối xứng bằng Box B. Nếu x quá dài và đã được đề cập thì cĩ thể ký hiệu tắt là B(…) trong đĩ B là tên của Box; s(x) là bản mật của bản rõ x được mã hĩa phi đối xứng bằng khĩa siêu mật của Server. Nếu x quá dài và đã được đề cập thì cĩ thể ký hiệu tắt là s(…); 0 là các bit 0 và Data là dữ liệu.
Bảng 3.6 sẽ chỉ ra thành phần thơng điệp trong giai đoạn 1: Khởi tạo.
Bảng 3.6. Thành phần thơng điệp trong của giao thức CurveCP
Thơng điệp Bên gửi Bên nhận Nội dung
Hello Client Server Hello(0), C’(P), N(C’(P))
Cookies Server Client Cookies(s(C’(P), N(C’(P)), S’(S), N(S’(S))), S’(P)), N(S’(P)) Initiate Client Server s(C’(P),N(C’(P)), S’(S), N(S’(S)), Initiate(Vouch(C’(P), S’(P)), C(P)), N(C’(P)) Ở giai đoạn 2: Trao đổi dữ liệu, cho dù là Server gửi Client hay Client gửi Server, thơng điệp hai bên sẽ như sau: Client gửi Server: CMessage(Data), N(C’(P)), Server gửi Client: SMessage(Data), N(S’(P)). Bảng 3.7 sẽ chỉ rõ hoạt động của từng Box trong giao thức CurveCP.