Triển khai CurveCP trên mạng WSN

3. SỬ DỤNG MÃ HÓA NHẸ CHO CÁC THIẾT BỊ IOT TÀI NGUYÊN YẾU

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 toà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à hoà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 hoà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ệ toà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 toà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 soá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 toá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. Ngoà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.

Bảng 3.7. Hoạt động của Box trong giao thức CurveCP

Box Vị trí Mã hóa Giải mã Nội dung bản rõ

Hello Client C’(S) S(P) 0

Cookies Server S’(S) C’(P) s(…), S’(S), N(S’(P)

Vouch Client C(S) S’(P) C’(P), S’(P)

Initiate Client C’(P) S’(S) V(…), C(P)

CMessage Client C’(P) S’(S) Data

SMessage Server S’(P) C’(S) Data

Mã hóa CurveCP sử dụng nguyên tắc: “Khóa mã hóa và khóa giải mã không đến từ cùng một bên cung cấp”. Có nghĩa là Box chỉ được mã hóa bằng khóa của bên

96

gửi và giải mã bằng khóa của bên nhận. Ưu điểm của phương pháp này là cho phép phục vụ mục đích xác thực và bảo mật thông tin. Bởi vì Box chỉ được giải mã bằng khóa phiên mật của bên nhận nên sự an toàn được đảm bảo trong khi, trong giao thức phân phối khóa, chỉ có bên nhận có được khóa phiên công khai của bên gửi nên sẽ đảm bảo chỉ có bên nhận mới mã hóa được thông điệp đó.

Như vậy giao thức CurveCP sử dụng một cơ chế mã hóa kết hợp xác thực và mã hóa dữ liệu nhằm tiết kiệm công suất tính toán cho mạng IoT nhưng vẫn đảm bảo mục đích chính là giúp mạng IoT nâng cao khả năng phòng chống các cuộc tấn công nghe lén và giả mạo dữ liệu nâng cao sự an toàn trong tính toàn vẹn và tính bảo mật của dữ liệu.

b. Điều chỉnh giao thức CurveCP

Các điều chỉnh này sẽ diễn ra trên cả ba loại thông điệp bao gồm Thông điệp Hello, Thông điệp Cookies và thông điệp Initiate. Cụ thể, tất cả 8 khóa (mỗi nút 4 loại khóa) bao gồm các khóa như đã ký hiệu trên Bảng 3.3 bao gồm C(P), C(S), C’(P), C’(S) ở Client và S(P), S(S), S’(P) S’(S) ở Sever đều có độ dài là 32 bit, sẽ được giảm xuống còn 16 bits.

Cụ thể, tất cả 8 khóa (mỗi nút 4 loại khóa) bao gồm các khóa như đã ký hiệu trên Bảng 3.4 bao gồm C(P), C(S), C’(P), C’(S) ở Client và S(P), S(S), S’(P) S’(S) ở Sever đều có độ dài là 32 bits, sẽ được giảm còn 16 bit. Với việc giảm như vậy, thời gian tính toán của từng lần mã hóa trong thuật toán sẽ ít hơn, mặc dù vậy các điều chỉnh này cũng làm độ bảo mật của giao thức CurveCP bị giảm đi do độ dài khóa ngắn sẽ khiến cho nguy cơ bị tấn công vét cạn thành công trở nên lớn hơn. Mặc dù vậy rõ ràng là mục tiêu của giao thức bảo mật như CurveCP, ngoài bảo vệ an toàn dữ liệu, còn phải đảm bảo hiệu năng hoạt động của mạng IoT và vai trò của giao thức bảo mật sẽ là vô nghĩa nếu hoạt động của giao thức đó làm mạng bị ngưng trệ và không đạt yêu cầu hiệu năng. Chính vì lý do đó, việc đánh đổi giữa độ mạnh trong tính bảo mật của giao thức CurveCP với độ tiêu thụ tài nguyên của giao thức này trong toàn hoạt động mạng IoT là cần thiết.

3.4.2. Thử nghiệm triển khai CurveCP với các điều chỉnh

Hệ điều hành Contiki có những ưu điểm nổi trội, đã được triển khai với nhiều nghiên cứu khoa học khác nhau nên có đầy đủ cơ sở hạ tầng, tài nguyên để thực hiện,

97

do đó để đảm bảo tính tối ưu, do vậy luận án tiếp tục sử dụng hệ điều hành này để mô phỏng giải pháp CurveCP.

Thư viện mã nguồn “curvecp” về giao thức CurveCP trên hệ điều hành Contiki OS được viết bởi Jan Mojzis trong dự án phát triển cơ chế Tiny SSH cho mạng IoT với việc kế thừa các giao thức bảo mật trong Networking and Cryptography library (NaCl) cũng do nhóm nghiên cứu của Daniel J. Bernstein thiết kế. Do giao thức này sử dụng thư viện MUSL được phát triển bởi Rich Felker vào năm 2011 [84], nên việc cần làm đầu tiên là cài đặt thư viện MUSL cũng như toàn bộ tham chiếu đến thư viện này trong Hệ điều hành Contiki OS sẽ mô phỏng mạng IoT. Việc cài thư viện MUSL bao gồm 2 bước là tải thư viện mã nguồn “musl” về và cấu hình trên hệ điều hành Contiki OS.

Giao thức này chỉ hoạt động bên trong môi trường mô phỏng mạng IoT nên phải tiếp tục tải thư mục “contiki-master” chứa các mã nguồn mô phỏng hoạt động nút mạng IoT trong thực tế cũng như môi trường thí nghiệm Cooja. Mã nguồn “curvecp” sẽ được cài đặt trong thư mục “apps” của “contiki” vì đây là thư mục lưu trữ các giao thức bên ngoài bổ trợ cho mạng IoT. Ngoài ra, vì có hai kịch bản là kịch bản CurveCP có điều chỉnh giảm độ dài mã, và kịch bản CurveCP thông thường không có tùy biến, nên cần sao lưu thành hai thư mục giống nhau là “curvecp” và “improved-curvecp”. Với những kịch bản điều chỉnh trên giao thức CurveCP thì việc giảm độ dài mã khóa sẽ được diễn ra trên file cấu hình “crypto-block.IoT” trong thư mục “src” ở thư mục “improved-curvecp” (mã lệnh được mô tả trong Phụ lục Hình 10 (PL)).

Sau khi đã cài đặt xong thì việc cuối cùng là cài đặt tham chiếu lên kịch bản mô phỏng nằm ở file “project-conf.IoT” trong thư mục “rpl-udp” có đường dẫn “contiki-master/examples/ipv6/” bằng cách thêm vào tham chiếu sau:

Với CurveCP nguyên bản: APPS += curvecp

Với CurveCP có điều chỉnh: APPS += improved-curvecp

Ngoài ra, cũng cần lưu ý rằng giao thức CurveCP có hai phiên bản riêng biệt: một dành cho Server và một dành cho Client. Trước các tệp cấu hình thông số nút mạng phải thêm dòng mã nguồn tham chiếu đến phiên bản của giao thức CurveCP.

98

File “sensor-node.c”, nút Client thêm dòng: initiate_server_curvecp().

Sau quá trình cấu hình thì cấu hình toàn bộ phục vụ giao thức CurveCP đã hoàn thành. Công việc tiếp theo là xây dựng mô hình và kịch bản thí nghiệm.

Mục tiêu của thí nghiệm là cho thấy sự khả thi trong triển khai giao thức CurveCP vào mạng IoT mô phỏng, cho thấy hoạt động của giao thức CurveCP không gây ảnh hưởng lớn về tốc độ, hiệu năng thông thường và mạng IoT vẫn hoạt động bình thường. Sẽ có 3 tình huống trên cùng mô hình mạng IoT là kịch bản có cài giao thức CurveCP điều chỉnh và kịch bản không cài giao thức CurveCP, cài đặt CurveCP nguyên bản, từ đó sẽ dễ dàng so sánh và đối chiếu giữa các trường hợp với nhau, thời gian là mỗi tình huống là 60 phút.

3.4.3. Kết quả thí nghiệm mô phỏng với giải pháp điều chỉnh CurveCP

Trên toàn bộ WSNs, trên từng kịch bản cả ba thông số đo đạc, giá trị từng thông số đo đạc 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í của nút mạng. 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.3, sẽ có giá trị như sau dựa trên thông số kỹ thuật của hãng Moteiv [55]: Et = 19.5; Er = 21.8; Eo = 1.8; EI = 0.545 và τ = 2345+2

Kết quả sẽ được biểu thị trong Bảng 3.9:

Bảng 3.8. Kết quả đo thông số mạng IoT với CurveCP

Loại mạng PDR

(%) Latency (ms/m) Energy Consumption (mJ)

Không cài CurveCP 98.67 543.98 119.21

Cài CurveCP nguyên bản 92.13 893.24 287.90

Cài CurveCP điều chỉnh 95.04 700.13 219.81

Từ dữ liệu thu thập được ở Bảng 3.8, ta có một số nhận xét như dưới đây. - Thứ nhất, Giao thức CurveCP nguyên bản đã tiêu thụ nhiều tài nguyên mạng IoT, khiến hiệu năng mạng không đạt yêu cầu về cả ba tiêu chí. Cụ thể PDR đã ở dưới ngưỡng cho phép là 95% [44] trong khi Độ trễ đã ở vượt mức cho phép là 800 ms [47]. Về năng lượng, mặc dù tiêu thụ năng lượng chưa vượt ngưỡng cho phép nhưng năng lượng tiêu thụ cũng gần gấp đôi khi mạng không cài giao thức CurveCP.

- Thứ hai, Giao thức CurveCP khi đã được điều chỉnh giảm độ dài mã hóa, vẫn tiêu thụ tài nguyên nhưng ít hơn và vì thế hiệu năng mạng vẫn đảm bảo ngưỡng cho phép. Năng lượng tiêu thụ cũng tăng lên so với mạng không cài đặt nhưng không quá

99 nhiều.

Tổng kết lại, giao thức CurveCP sau khi điều chỉnh hoàn toàn có thể được triển khai trên mạng IoT và đảm bảo tiêu thụ năng lượng không ảnh hưởng xấu đến hoạt động của mạng, đảm bảo được tính bí mật của thông tin sau khi đã mã hóa.

Mục tiêu, phù hợp với điều kiện các thiết bị tài nguyên yếu. Với các điều chỉnh đề xuất đáp ứng được 2 nội dung:

• Triển khai được trên thiết bị tài nguyên yếu

• Đảm bảo hiệu năng toàn hệ thống mạng IoT

Kết quả của giải pháp được trình bày trong “Hội nghị quốc tế lần thứ ba về các mô hình tính toán và truyền thông nâng cao (ICACCP 2021)” xuất bản trên Springer, và bài báo [9] tại tuyển tập các công trình công bố của luận án.

3.5. Giới thiệu hàm băm xác thực hạng nhẹ Quark

Như đã trình bày, điểm yếu của môi trường cảm biến trong WSN là tài nguyên bị giới hạn, không thể đảm bảo WSN hoạt động ổn định khi phải chia sẻ tài nguyên với các giao thức an toàn bảo mật vốn dành cho mạng Internet không bị giới hạn tài nguyên, đặc biệt là các giao thức mã hóa. Chính vì vậy, phương hướng khi tích hợp các giao thức an ninh và an toàn thông tin là tận dụng các lý thuyết an ninh của các giao thức bảo mật an ninh hiện có mà đã được minh chứng tính tin cậy và sau đó, nghiên cứu giảm khả năng tiêu thụ tài nguyên để có thể tích hợp các giao thức mới vào WSN mà không làm ảnh hưởng tới hoạt động các giao thức này. Bản thân giao thức DTLS cũng được kế thừa từ giao thức TLS với sự giản lược một số chức năng và việc cải tiến giao thức DTLS để có thể tích hợp được cơ chế Overhearing cũng theo cách tiếp cận giảm tiêu thụ tài nguyên thông qua giảm độ dài khóa. Hiện nay, có rất nhiều cơ chế mã hóa nhẹ đã và đang được nghiên cứu phát triển dựa trên từng yêu cầu bài toán khác nhau. Trong số đó, cơ chế băm Quark là được nghiên cứu và phát triển Jean-Philippe Aumasson sử dụng cho WSN cỡ nhỏ. Chính vì băm Quark được phát triển chuyên biệt cho WSN cỡ nhỏ như hệ thống RFID nên độ tiêu thụ tài nguyên nhỏ và vì thế được xem xét tích hợp vào giải pháp an ninh tổng thể [78]. Quark hoạt động theo cơ chế nổi bọt chồng (padded sponge construction) được giới thiệu bởi Guido Bertoni [79], với các hàm băm chồng lên nhau mà đầu ra của hàm băm này sẽ là đầu vào của hàm băm sau. Mục đích của cơ chế nổi bọt chồng là tăng độ khó trong