3. SỬ DỤNG MÃ HĨA NHẸ CHO CÁC THIẾT BỊ IOT TÀI NGUYÊN YẾU
3.3. Giải pháp DTLS xác thực và bảo mật cho các thiết bị tài nguyên yếu
3.3.3. Thử nghiệm và đánh giá mơ hình an ninh DTLS
a. Mơi trường và thiết bị triển khai thử nghiệm
Phần này triển khai thử nghiệm hệ thống giám sát và theo dõi sức khỏe bệnh nhân bằng cảm biến IoT y tế theo mơ hình đề xuất. Tuy nhiên phạm vi thử nghiệm của luận án chỉ tập trung triển khai một phiên bản thử nghiệm đơn giản của hệ thống để đánh giá tính khả thi của cơ chế truyền nhận dữ liệu an tồn giữa các thiết bị cảm biến và OM2M bằng giao thức DTLS. Minh họa như Hình 3.4, gồm 3 thành phần chính:
+ Bộ cảm biến IoT (Cụm a): bao gồm một cảm biến điện cơ, cảm biến ghi lại hoạt động căng chùng của cơ bắp nối với một mạch điều khiển eHealth. eHealth là một bộ cảm biến IoT điện tử được phát triển và sản xuất bởi cơng ty Libelium. Một mạch điều khiển eHealth cĩ thể kết nối với 10 loại cảm biến IoT điện tử cầm tay như cảm biến huyết áp, nhịp tim, lượng đường trong máu, phế dung, điện cơ, … để cĩ thể điều khiển đo đạc các thơng số về sức khỏe của bệnh nhân một cách tự động và thu thập được các kết quả đo dưới dạng dữ liệu số. Mạch điều khiển eHealth được kết nối với một mạch Zolertia RE-Mote để cĩ thể truyền và nhận dữ liệu thơng qua chuẩn năng lượng thấp IEEE 802.15.4. RE-Mote (vi xử lý CC2538 ARM Cortex-M3 32MHz, 512KB ROM, 32KB RAM) là một mạch phần cứng được phát triển bởi dự án RERUM (REliable, Resilient, and secUre IoT for sMart city applications).
+ Gateways (Cụm b) được tích hợp dựa trên Zolertia RE-Mote và ENC28J60. ENC28J60 hỗ trợ chuẩn RJ45, được kết nối trực tiếp đến một Wireless Router (Cụm c) và được gắn với một địa chỉ IPv4 trong mạng. Các thiết bị trong mạng cảm biến khơng dây đều được gán địa chỉ IPv6. Gateway định tuyến trong mạng cảm biến dựa trên giao thức RPL và làm cầu nối giữa hai mạng khơng đồng nhất.
+ Thành phần IN và MN dựa trên mã nguồn mở OM2M được tích hợp tương ứng trên 2 máy tính với cấu hình Ubuntu 16.04, vi xử lý Intel Core i5, Ram 8GB.
88
Ứng dụng giám sát tình trạng sức khỏe được phát triển bởi ngơn ngữ PHP và được tích hợp trên cùng máy chủ vật lý với thành phần IN.
Để thiết lập kênh truyền bảo mật giữa bộ cảm biến IoT y tế và MN bằng giao thức DTLS, trên REMote cần phải triển khai chương trình DTLS server và tích hợp DTLS Client dưới dạng một plugin trong CSE của MN. Thư viện được sử dụng trong phần thử nghiệm là tinyDTLS với phương thức bảo mật TLS PSK WITH AES 128 CCM 8, TLS ECDHE ECDSA WITH AES 128 CCM 8 [36] sử dụng thư viện tinyDTLS nhưng thử nghiệm với khĩa chia sẻ trước và khơng thể thực hiện xác thực thiết bị, vốn là yêu cầu rất quan trọng trong các ứng dụng IoT y tế, trong đĩ dữ liệu gửi về phải đảm bảo tính tồn vẹn, xác thực và độ tin cậy cao. Một số cơng trình khác đề cập khĩa chia sẻ trước với các phương thức như AES-CCM hoặc AES-GCM. AES-CCM và AES-GCM xây dựng hệ thống quản lý khĩa phù hợp tại máy chủ MN.
Hình 3.4. Các thành phần trong hệ thống thử nghiệm b. Kết quả thử nghiệm, so sánh, đánh giá và nhận xét b. Kết quả thử nghiệm, so sánh, đánh giá và nhận xét
Bảng 3.4 minh họa thời gian xử lý tương ứng với từng bước của giao thức DTLS. Việc đo đạc trên MN là khơng cần thiết do phân hệ này được triển khai trực tiếp trên máy tính với hiệu năng cao. Vì thế, Bảng 3.4 chỉ đưa ra các giá trị tương ứng với DTLS trên các thiết bị cảm biến gồm 8 bước. Trong mơ hình đề xuất, thiết bị cảm biến nhận và trả lời yêu cầu từ phân hệ MN nên đĩng vai trị là máy chủ (server) trong mơ hình khách/chủ. Cĩ thể thấy, thời gian xử lý chủ yếu tập trung vào hai bước: trao đổi khĩa (ServerKeyExchange) (khoảng 20 giây) và thay đổi phương thức mã hĩa
89
(ChangeCipherSuite) (khoảng 10 giây). DTLS sử dụng thuật tốn mã hĩa dựa trên đường cong Elliptic (ECC) với độ dài khĩa ngắn. Tuy nhiên, vấn đề trao đổi khĩa lại dựa trên tính một chiều của hàm logarit rời rạc với một số nguyên tố đủ lớn, nên địi hỏi nhiều phép tính phức tạp. Bước (5) được bỏ qua do việc xác thực chữ ký số thường dẫn đến tràn bộ nhớ RAM và khởi tạo lại tồn bộ quá trình bắt tay. Mặc dù vậy, việc gửi chứng thư của thiết bị vẫn được tiến hành tại Bước (3) với mục tiêu đảm bảo tính tồn vẹn và xác thực của dữ liệu khi nhận được tại MN.
Bảng 3.4. Quá trình bắt tay của DTLS tại thiết bị
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.