3. SỬ DỤNG MÃ HÓA NHẸ CHO CÁC THIẾT BỊ IOT 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 toà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 toà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ả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 toá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 toà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 toà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 hoàn toà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. Ngoà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ì toà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 toán mã hóa có thể được giải mã bằng thuật toá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 toán Differ – Helman [97]. Ngoài hai thuật toá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 toán băm SHA và cơ chế phục hồi dữ liệu EEC. Ngoà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 toàn mạng. Chấp nhận giảm mức độ an toà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 toà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 toá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.