物聯網互操作性和安全性 API 設計案例研究

核心概念

本文提出了一種 API 設計方法和運行時，旨在通過支援多種通訊模型和靈活的安全框架，來增強物聯網和分散式 CPS 的互操作性和安全性。

摘要

書目資訊

Kim, D., Lee, C., & Kim, H. (2024). A Case Study of API Design for Interoperability and Security of the Internet of Things. In Proceedings of the 2nd EAI International Conference on Security and Privacy in Cyber-Physical Systems and Smart Vehicles (SmartSP 2024).

研究目標

本研究旨在設計和實作一種 API 和運行時，以解決物聯網和分散式網路物理系統 (CPS) 中日益嚴重的互操作性和安全性問題。

方法

• 設計了一個支援多種通訊模型的 API，包括點對點（例如，客戶端-伺服器）和發佈-訂閱範例，以促進異構設備之間的無縫互動。
• 結合了一個靈活的安全框架，可以根據不同的安全需求進行調整應用。
• 使用開源軟體開發了一個有效的運行時系統，以展示 API 的實用性，並評估其效能，表明它以相當小的開銷實現了互操作性和安全性，同時簡化了軟體開發並增強了可維護性。

主要發現

• 所提出的 API 能夠有效地支援不同的通訊模型，促進異構設備之間的互操作性。
• 整合的安全框架在確保資料機密性和完整性方面表現出有效性，同時保持合理的效能開銷。
• 基於開源軟體的案例研究實作證明了該方法的實用性和潛在的實際應用。

主要結論

該研究證明，精心設計的 API 和運行時可以有效解決物聯網和分散式 CPS 中的互操作性和安全性挑戰。 通過採用靈活且可適應的方法，該研究為開發更安全、更互operable的物聯網生態系統做出了貢獻。

意義

本研究對物聯網和分散式 CPS 領域具有重要意義，它提供了一種增強異構設備和應用程式之間互操作性和安全性的實用方法。 該研究的結果可以指導開發更強大、更值得信賴的物聯網系統。

局限性和未來研究

• 該研究主要集中在兩個具有代表性的通訊模型上，探索其他模型（例如，訊息佇列）將進一步增強該方法的適用性。
• 雖然安全框架顯示出積極的結果，但評估更廣泛的安全威脅和漏洞對於全面評估至關重要。
• 未來的研究工作包括在更大、更複雜的物聯網部署中評估 API 和運行時，以評估其可擴展性和效能。

統計資料

使用 ping 測試的 Raspberry Pi 到工作站的平均端到端往返延遲為 13.60 毫秒。
與基準程式碼相比，當週期為 500 毫秒時，TCP 模型的延遲增加了 0.53%，即 0.08 毫秒。
SST 模型的延遲也增加了 0.80%。
將 SST 模型與 TCP 模型進行比較，啟用安全性以進行聯合身份驗證和訊息的機密性/完整性時，延遲僅增加了 0.26%。
50 毫秒週期測試也具有類似的趨勢，顯示出非常小的開銷。
由於同步行為，MQTT 的延遲時間更長。
每個 netdrv write() 函數呼叫平均需要 90 毫秒才能傳輸訊息。
基準程式碼和客戶端-伺服器模型都基於 TCP，因此它們的 TCP/IP 標頭長度相同，為 66 位元組，共發送 91 位元組。
MQTT 模型發送了 118 位元組，包括 66 位元組的 TCP/IP 標頭和 27 位元組的 MQTT 標頭。
SST 模型總共發送了 164 位元組，包括 TCP/IP 標頭、SST 標頭和加密訊息。
對於 TCP、MQTT 和 SST，RTI 的二進制大小分別增加了 1.02%、5.23% 和 1.44%。
對於相同的協定，Destination 聯合的二進制大小分別增加了 7.29%、3.71% 和 7.67%，而 Source 聯合的增長幅度相似。

引述

從以下內容提煉的關鍵洞見

A Case Study of API Design for Interoperability and Security of the Internet of Things

by Dongha Kim, ... 於 arxiv.org 11-21-2024

https://arxiv.org/pdf/2411.13441.pdf

深入探究

在實際應用場景中，如何確保所提出的 API 設計能夠與各種新興物聯網標準和協定相容？

為了確保所提出的 API 設計在實際應用中能與各種新興物聯網標準和協定相容，可以考慮以下幾點：
1. 採用模組化設計，支援可擴展性：

將 API 設計成模組化的結構，允許輕鬆地添加新的功能模組，以支援新的物聯網標準和協定。
例如，針對不同的通訊協定（例如，MQTT、CoAP、HTTP 等），可以設計獨立的 API 模組，並通過統一的介面進行調用。
當需要支援新的協定時，只需開發新的模組，而無需修改現有的程式碼，從而提高 API 的可擴展性和可維護性。
2. 使用標準化的資料格式和語義：

在 API 設計中，盡可能使用標準化的資料格式（例如，JSON、XML 等）和語義模型（例如，SensorML、OneM2M 等）。
這將有助於不同廠商的設備和應用程式之間實現互操作性，並降低資料整合的複雜度。
可以考慮使用語義網技術（例如，RDF、OWL 等）來描述資料的語義，以便於機器理解和自動化處理。
3. 積極參與標準制定和開源社區：

積極參與相關的物聯網標準制定組織（例如，IETF、OMA、W3C 等）和開源社區（例如，Eclipse Foundation、Open Connectivity Foundation 等）。
及時了解最新的標準和技術發展趨勢，並將其融入到 API 設計中。
參與開源專案可以促進程式碼共享和技術交流，有助於提高 API 的品質和相容性。
4. 提供完善的文件和範例程式碼：

提供清晰、完整、易於理解的 API 文件，說明 API 的功能、參數、返回值、錯誤處理等資訊。
提供豐富的範例程式碼，演示如何使用 API 與不同廠商的設備和應用程式進行交互。
完善的文件和範例程式碼可以降低開發者的學習成本，並促進 API 的推廣和應用。

如果物聯網設備資源受限，無法支援複雜的加密演算法，那麼如何調整安全框架以在安全性與效能之間取得平衡？

針對資源受限的物聯網設備，在安全性與效能之間取得平衡至關重要。以下是一些調整安全框架的策略：
1. 選擇輕量級加密演算法：

使用輕量級加密演算法，例如：

對稱加密： AES-128、ChaCha20
非對稱加密： ECC (Elliptic Curve Cryptography)
訊息鑑別碼： HMAC-SHA-256

這些演算法在計算複雜度和資源消耗方面相對較低，適合資源受限的設備。
2. 簡化金鑰管理：

採用預先共享金鑰 (PSK) 或基於身份的加密 (IBE) 等輕量級金鑰管理方案，減少金鑰協商和儲存的開銷。
例如，可以使用物理不可複製函數 (PUF) 或輕量級金鑰派生函數 (KDF) 來安全地產生和儲存金鑰。
3. 採用混合安全機制：

結合不同的安全機制，例如：

在設備端使用輕量級加密，而在閘道器或雲端伺服器上使用更強大的加密。
僅對敏感資料進行加密，而對非敏感資料使用較低的保護級別。

這種混合方法可以在確保安全性的同時，最大程度地減少資源消耗。
4. 利用邊緣計算資源：

將部分安全功能（例如，加密、解密、金鑰管理等）卸载到邊緣計算節點，減輕設備的負擔。
邊緣節點通常擁有更強大的計算能力和儲存空間，可以提供更高級別的安全保護。
5. 定期更新安全策略：

隨著技術的發展和攻擊手段的變化，定期評估和更新安全策略，以應對新的威脅。
監控設備和網路的安全性，並及時修補漏洞。

除了技術層面的考量，API 設計的哪些方面可以促進物聯網系統中更廣泛的互操作性和協作，例如開發者生態系統和資料共享實務？

除了技術層面，API 設計的其他方面也能促進物聯網系統的互操作性和協作：
1. 開發者生態系統：

清晰易懂的 API 文件： 提供結構清晰、內容詳盡的文件，包含使用範例、程式碼片段、常見問題解答等，降低開發者學習和使用 API 的門檻。
活躍的開發者社群： 建立論壇、聊天室等線上平台，方便開發者交流經驗、分享資源、尋求幫助，促進知識共享和問題解決。
易於使用的開發工具： 提供軟體開發套件 (SDK)、程式碼產生器、測試工具等，簡化開發流程，提高開發效率。
開放的 API 授權協議： 採用 Apache 2.0、MIT 等寬鬆的授權協議，鼓勵開發者使用、修改和分享 API，促進生態系統的繁榮。
2. 資料共享實務：

標準化的資料格式和語義： 使用 JSON、XML 等標準資料格式，並參考 SensorML、OneM2M 等語義模型，確保不同設備和應用程式理解資料的含義。
資料授權和隱私保護： 提供 API 控制資料訪問權限，並遵循 GDPR、CCPA 等資料隱私法規，保障使用者隱私和資料安全。
資料品質和可靠性： 設計 API 時考慮資料驗證、錯誤處理、版本控制等機制，確保資料的準確性、完整性和一致性。
資料可發現性和可訪問性： 使用標準化的 API 查詢語言 (例如，GraphQL) 和資料目錄服務，方便開發者搜尋和訪問所需的資料。
總之，良好的 API 設計不僅要考慮技術因素，還要關注開發者生態系統和資料共享實務，才能真正促進物聯網系統的互操作性和協作。