Sử dụng giao thức trao đổi khóa hạng nhẹ trong IoT

 

Các thiết bị trong môi trường IoT thường có hạn chế về năng lượng (do sử dụng pin), khả năng xử lý và có bộ nhớ thấp (thường từ vài KB RAM đến hàng chục KB EEPROM). Do đó, giao thức trao đổi khóa cần sử dụng các cơ chế hạng nhẹ bao gồm: khóa mật mã đối xứng và sơ đồ dẫn xuất khóa dựa trên hàm băm (Hash key derivation function - HKDF)

 

Trong [1] đề xuất giao thức trao đổi khóa hạng nhẹ, gồm 2 khóa chia sẻ giữa thiết bị IoT và Gateway, trong đó sử dụng một khóa chủ đối xứng dài hạn, ký hiệu là Km, và một khóa chia sẻ ngắn hạn (khóa phiên) ký hiệu là Ks. Khóa phiên khởi tạo được ký hiệu là Kiks. Cả khóa chủ và khóa phiên khởi tạo được nhập thủ công một lần vào trong bộ nhớ EEPROM của thiết bị IoT và Gateway. Mỗi Gateway xác thực thiết bị IoT thông qua các Message trao đổi giữa hai bên, các Message được mã hóa bởi khóa chủ Km và được băm nhờ khóa Kiks. Giao thức này đảm bảo cả hai bên đều có khóa chia sẻ Ks, được dùng để mã hóa và tính giá trị băm cho Message phiên. Điều quan trọng, cần đảm bảo là các khóa bí mật không được chia sẻ trực tiếp qua mạng. Việc xác thực lại và cập nhật khóa phiên Ks được thực hiện thường xuyên. Các Message được trao đổi giữa những lần cập nhật được gọi là “phiên”. Mỗi phiên có một ngưỡng, là số lượng lớn nhất các frame được trao đổi trong phiên. Việc cập nhật khóa phiên Ks được dựa trên tập hợp ngẫu nhiên các frame trao đổi ở phiên trước cũng như khóa Ks trước, và khóa Km. Như vậy, kể cả khi kẻ tấn công tìm ra Ks ở một thời điểm nào đó, cũng không thể tìm ra khóa phiên tiếp theo để giải mã, trừ khi kẻ tấn công biết cả Km và Ks hiện hành.

 

Ngoài ra, thiết bị IoT và Gateway có thể phải làm việc trong môi trường không có kết nối, khả năng truy cập đến bên thứ ba tin cậy cũng cần hạn chế. Hình 1 mô tả một mạng IoT tổng quát bao gồm nhiều thiết bị IoT và một Gateway, trong đó các thiết bị IoT liên kết với nhau thông qua Gateway.

 

Như đã trình bày ở trên, mỗi cặp thiết bị IoT và Gateway chỉ có một cặp duy nhất Km và Ks, cặp khóa này đóng vai trò quan trọng trong việc xác thực. Các thiết bị IoT và Gateway được xác thực thông qua các Message được mã hóa với khóa chia sẻ Km và được tính giá trị băm với khóa Kiks, khóa Ks dùng để mã hóa và tính giá trị băm của Message trong một phiên. Giao thức tạo ra mã hóa xác thực sử dụng chế độ làm việc Counter với CBC -MAC (CCM). Chế độ này đảm bảo tính bí mật và xác thực Message trong tất cả các pha. Với chế độ này CCM, CBC-MAC được dùng để tính một mã xác thực Message (MAC) cho tất cả các khung (header, nonce và payload) bằng cách sử dụng một khóa bí mật đối xứng (Km  hoặc Ks phụ thuộc vào từng pha). Còn chế độ bộ đếm Counter được dùng để mã hóa tải payload như là MAC, bằng cách sử dụng một giá trị nonce và khóa bí mật đối xứng (Kiks hoặc Ks tùy vào pha). Khi số lượng frame đạt đến ngưỡng cho trước thì bắt đầu một phiên mới.

 

Ks được cập nhật thường xuyên, và không được trao đổi qua mạng. Khi cập nhật Ks mới sẽ sử dụng giá trị Ks trước đó, có nghĩa là khóa phiên mới Ks phụ thuộc vào khóa phiên.

 

Giao thức [1] đã đề xuất được các ưu điểm của tính ngẫu nhiên trong các frame thông thường, và dùng nó để tạo tính ngẫu nhiên của các khóa phiên. Phần tiếp theo sẽ giới thiệu về pha xác thực dành cho thiết bị IoT mới.

 

 

Khi một thiết bị IoT lần đầu tiên tham gia vào mạng, bước khởi tạo ban đầu cần cung cấp cho cả thiết bị IoT và Gateway khóa thỏa thuận Ks. Điều này được thực hiện bằng cách cài thủ công khóa chia sẻ Km và Kiks (đã được cài vào Gateway) vào thiết bị IoT mới. Hình 2 mô tả các bước của việc khởi tạo thiết bị IoT mới, bao gồm:

 

Message 1: Thiết bị IoT gửi ID1, một giá trị khởi tạo, Nonce1 và MACKiks(Message 1), được mã hóa bởi  Km đến Gateway. Để chứng minh tính chân thực của định danh, thiết bị IoT mới đưa ra thử thách Nonce1. Kiks được dùng để tính MAC cho cả Message.

 

Message 2: Phụ thuộc vào việc nhận Message 1 từ thiết bị IoT, Gateway sẽ lựa chọn một tập hợp ngẫu nhiên của frame dự kiến RandFrmSeqsi+1, để cập nhật khóa Ks lần tiếp theo. Sau đó gửi lại Nonce2 (một thử thách mới của Gateway) và Nonce1 cho thiết bị IoT như là một phần của Message 2. Nonce2, RandFrmSeqsi+1 và Nonce1 sẽ được mã hóa với khóa chủ để đảm bảo tính bí mật trong trao đổi với thiết bị IoT.

 

Message 3: Khi thiết bị IoT nhận được Message 2, nó khẳng định rằng giá trị băm của MAC nhận được phù hợp với giải mã Message thông qua Km. Thiết bị IoT sẽ đánh dấu Gateway đã được xác thực, khẳng định thiết bị IoT đã nhận được tập RandFrmSeqsi+1. Ngoài ra, thiết bị IoT biết Gateway có khóa đúng Kiks và nhận Nonce1 đúng từ Message 1 và xác thực Gateway, sau đó gửi lại Message 3 cho Gateway.

 

Message 4: Khi Gateway nhận Message 3, nó kiểm tra MAC. Nếu đúng, Gateway đánh dấu thiết bị IoT là được xác thực, và Gateway biết thiết bị IoT có khóa đúng Kiks và nhận được Nonce2 trực tiếp từ Message 2. Gateway gửi IDG, kết quả mã hóa “ack” và MACKik (Message 4) sử dụng Km đến thiết bị IoT để khẳng định Message 3 đã được nhận đúng bởi Gateway. Gateway có Ks là khóa dẫn xuất ngẫu nhiên từ Nonce1 và Nonce2, sử dụng như đầu vào salt (một giá trị ngẫu nhiên), sử dụng Kiks như là khóa HKDF.

 

 

 Trong đó, cả hai thiết bị dựa trên Ks, và chúng trao đổi an toàn nhờ Ks. Trong pha này, cả hai thiết bị giữ các frame tương ứng thông qua RandFrmSeqsi+1 và được dùng cho khóa Ks cho đến ngưỡng frame đạt được. Đối phương không chỉ không biết RandFrmSeqsi+1, mà còn không biết tất cả các frame của phiên.

 

Message 1: Thiết bị IoT tính khóa Ks cho phiên tiếp theo, nó sẽ là khóa HKDF của khung ngẫu nhiên dựa trên RandFrmSeqsi được sử dụng như thông tin đầu vào, nhận được ở phiên trước, và Km (được dùng như là salt). Sau đó, thiết bị IoT gửi ID1 qua lệnh “update key”, Nonce1, cùng với MACKs(Message 1) được mã hóa với Km gửi đến Gateway.

 

Message 2: Khi nhận được cập nhật khóa, Gateway kiểm tra ngưỡng đã đạt được chưa. Nó tính Ks cho phiên mới, với khóa HKDF của phiên ngẫu nhiên trên RandFrmSeqsi như là đầu vào và Km, (được dùng như salt), cùng với khóa hiện thời Ks. Gateway tính MAC bằng cách sử dụng Ks như là khóa được liên lạc với thiết bị IoT trong bước này. Sau đó, Gateway gửi IDG và mã hóa Nonce2, RandFrmSeqsi+1 , Nonce1 và MACKs(Message 2) sử dụng  Km cho thiết bị IoT.

 

Message 3: Khi nhận được Message 2, thiết bị IoT đánh dấu Gateway đã được xác thực bằng việc kiểm tra MAC. Nó tính giá trị băm của Nonce2 và RandFrmSeqsi+1 phù hợp với hoạt động của Gateway. Sau đó, thiết bị IoT gửi   ID1 và mã hóa của h(Nonce2||RandFrmSeqsi+1) và MACKs(Message 2) sử dụng Km. Khi Gateway nhận được Message 3, sẽ xác nhận IoT được xác thực khi MAC được kiểm tra, và việc cập nhật khóa thành công.

 

Tiếp theo là việc xác thực lại và ổn định lại khóa phiên, được mô tả như trong Hình 5.

 

Khi có sự đồng bộ lỗi của Ks với lý do nào đó (có thể là do bị phá hoại hoặc lý do khác), cả hai bên cần thống nhất lại khóa Ks an toàn. Việc gọi lại cả Km và  Kiks được đảm bảo trong cả hai thiết bị với bộ nhớ không phụ thuộc vào điện. Vì vậy, cả hai thiết bị dùng Km và  Kiks để xác thực lại và ổn định lại một khóa mới Ks từ Nonce1, Nonce2 và Kiks, điều này sẽ tạo ra một khóa Ks khác với xác suất cao, được thực hiện mỗi khi khởi động lại Ks. Ví dụ, thiết bị IoT hoặc Gateway có thể khởi động lại vì lý do này, kết quả là cả hai phải được khởi động lại Ks cho khóa Ks mới ngẫu nhiên và xác thực lại, thỏa thuận lại khóa an toàn, được chỉ ra trong Hình 5. Tiến trình này tương tự như quá trình xác thực và thiết lập khóa, ngoại trừ lệnh « reset » thay cho lệnh « initialization ».

 

 

Phần này sẽ đánh giá an toàn cho giao thức đã giới thiệu phía trên. Theo các tác giả trong [1], việc có cả 2 khóa Km, Ks sẽ cung cấp độ an toàn tốt hơn, gây khó khăn cho kẻ tấn công muốn biết cả 2 khóa. Các phân tích đã chứng tỏ được nếu chỉ biết 1 khóa sẽ không đủ để lộ tính bí mật và tính toàn vẹn của Message. Các tác giả cũng chỉ ra rằng, giao thức được đề xuất thỏa mãn tính an toàn đầy đủ về phía trước (PFS- Perfect Forward Secrecy). Một số điểm chính bao gồm:

 

- Độ dài của khóa Km và Ks   phải đủ phức tạp để chống lại tấn công vét cạn.  

 

- Biết giá trị Km   là không đủ để giải mã các Message phiên, bởi vì chúng đã được mã bởi khóa khác.

 

- Các khóa phiên không được chuyển dưới dạng rõ, biết Km là không đủ để biết Ks.

 

- Thậm chí nếu biết Km, có một kênh hoàn thiện, và ghi tất cả Message từ nơi bắt đầu, chúng không sở hữu được Ks bởi vì các khóa không bao giờ được trao đổi dạng rõ trên mạng. Ngoài ra, kẻ tấn công không thể tính giá trị Ks hiện tại, bởi vì chúng phụ thuộc vào Ks trước đó.

 

- Nếu kẻ tấn công biết Ks và thậm chí chúng có cả kênh an toàn, thì vẫn không thể biết khung ngẫu nhiên được thỏa thuận để sinh khóa phiên tiếp theo.

 

- Nếu chỉ có Km được biết và thiết bị IoT khởi động lại hoặc kênh bị nghẽn bởi kẻ tấn công cũng ghi các Message được trao đổi, giao thức chống lại tấn công kẻ ở giữa một cách mạnh mẽ.

 

- Nếu kẻ tấn công chỉ biết Km ở pha khởi tạo, các tấn công ở giữa hoặc cướp phiên (session hijack) vẫn không thành công, bởi vì kẻ tấn công phải có khóa khác Kiks, để chứng minh tính hợp pháp cho bên còn lại.

 

 

Các tác giả trong [1] đã đề xuất giao thức trao đổi khóa và xác thực để đảm bảo liên lạc an toàn trong môi trường IoT. Giao thức được đề xuất có mục tiêu đảm bảo an toàn, hạng nhẹ, có năng lượng và không gian phù hợp, có xác thực và trao đổi khóa trên các thiết bị hạn chế tài nguyên. Độ an toàn của giao thức bao gồm các khóa bí mật được gửi dưới dạng mã trên đường truyền. Giao thức thường xuyên cập nhật các khóa phiên đối xứng thông qua việc mã hóa và băm dữ liệu dựa trên tham số ngẫu nhiên (đã đã thỏa thuận từ trước). Đồng thời cũng giới thiệu hai trở ngại, hai khả năng lộ lọt, có thể phá vỡ giao thức, đó là tổn thương khóa đối xứng dài hạn Km và khóa đối xứng ngắn hạn Ks. Trong giao thức được đề xuất, không có thành phần đơn lẻ nào bị lộ có thể ảnh hưởng đến nhiệm vụ xác thực và trao đổi khóa có thể gây ảnh hưởng đến tính bí mật cũng như tính toàn vẹn của Message được trao đổi.