TWI802447B - 感測器無線傳訊的封包加解密方法 - Google Patents

Abstract

一種感測器無線傳訊的封包加解密方法，應用於具有至少一個以上的感測器及至少一個以上的閘道器，包括下列步驟：感測器從記憶體中讀取安全上下文；由安全上下文中取得共同內文及傳送端ID，其中傳送端ID為感測器的ID；取得預設變數；依據共同內文、傳送端ID及預設變數產生傳送端加密鑰匙；以傳送端加密鑰匙對純文本加密以產生密文；依據標頭、傳送端ID及密文產生封包並傳送至閘道器。其中，閘道器依據與封包中的傳送端ID相關的資訊產生對應的接收端解密鑰匙，以對密文解密並取得純文本。

Description

感測器無線傳訊的封包加解密方法

本發明涉及感測器無線傳訊，尤其涉及應用在感測器無線傳訊中的封包加解密方法。

為了避免駭客攻擊，或是避免所傳送的資料被竊取，一般電腦設備在透過網路傳輸資料時，都會利用安全傳輸通道，或是對要傳送的資料進行加密。

然而，對於部分受約束的裝置(Constrained Devices)，例如感測器或是閘道器等物聯網(Internet of Things,IoT)裝置來說，因為硬體資源受限，不能像一般電腦設備一樣透過大量的運算來產生加解密用的金錀。因此，如感測器這種受約束裝置在傳輸資料時，並無法對資料進行加密，因而常常會面臨資訊安全的問題。另外，由於這些受約束裝置間的通訊屬於底層通訊，因此亦無法事先建立安全傳輸通道，如此也會造成資安問題。

舉例來說，當一台感測器要將資料發送至一台閘道器時，第三人只要知道感測器的資料格式，就可能從閘道器旁邊發動重送攻擊，以將具有相同資料格式的錯誤資料丟進閘道器中，而令閘道器或其他相關設備發生錯誤。

有鑑於此，上述受約束裝置間的通訊安全性，實有待本領域技術人員來加以提昇。

本發明的主要目的，在於提供一種感測器無線傳訊的封包加解密方法，可以令感測器無線傳訊下的發送端和接收端採用相同規則來對所傳送的封包進行加密與解密，藉此提高受約束裝置間的通訊安全性。

為了達成上述的目的，本發明的封包加解密方法主要可應用於具有感測器及閘道器的感測器無線傳訊，並且包括下列步驟：感測器從記憶體中讀取安全上下文；由安全上下文中取得共同內文及傳送端ID，其中傳送端ID為感測器的ID；取得預設變數；依據共同內文、傳送端ID及預設變數產生傳送端加密鑰匙；以傳送端加密鑰匙對純文本加密以產生密文；依據標頭、傳送端ID及密文產生封包並傳送至閘道器。其中，閘道器依據與封包中的傳送端ID相關的資訊產生對應的接收端解密鑰匙，以對密文解密並取得純文本。

本發明相對於相關技術所能達到的技術功效在於，傳送端和接收端可不經交握(Handshaking)而直接採用相同規則來對封包進行加密與解密，不但可提高資料安全性，亦可節省封包解譯時間進而提高傳輸效率；對於大規模的實體感測物聯網布建，整個網路的反應敏捷性因而提升。此外，感測器與閘道器間形成的封包加解密，可以解決目前物聯網感測器，多只是單向上傳資料，無法由 雲端平台經由閘道器下載感測器組態命令(例如感測取樣頻率)，達成雙向傳輸安全性的防護。

1:感測器

11:第一安全上下文

111:共同內文

112:傳送端ID

113:接收端ID

12:純文本

13:傳送端加密鑰匙

14:接收端解密鑰匙

15:序列號

2:閘道器

20:配置檔

21、201、202、203:第二安全上下文

211:共同內文

212:傳送端ID

213:接收端ID

22:純文本

23:傳送端加密鑰匙

24:接收端解密鑰匙

25:重播窗口

31:現行雲端伺服器

32:資訊伺服器

33:新雲端伺服器

P1:第一封包

P2:第二封包

S10~S24:傳送步驟

S30~S46:接收步驟

S50~S64:上傳步驟

圖1為本發明的感測器無線傳訊的示意圖的第一具體實施例。

圖2為本發明的加解密示意圖的具體實施例。

圖3為本發明的封包傳送流程圖的具體實施例。

圖4為CoAP資料格式的示意圖的具體實施例。

圖5為本發明的封包接收流程圖的具體實施例。

圖6為本發明的接收端ID的搜尋示意圖的具體實施例。

圖7為本發明的感測器無線傳訊的示意圖的第二具體實施例。

圖8為本發明的資料上傳流程圖的具體實施例。

茲就本發明之一較佳實施例，配合圖式，詳細說明如後。

首請參閱圖1，為本發明的感測器無線傳訊的示意圖的第一具體實施例。本發明主要揭露了一種感測器無線傳訊的封包加解密方法，並且此方法適用於一般性使用或是工業用的感測器無線傳訊。本發明中，所述感測器無線傳訊指的是具有一或多個感測器(sensor)1的環境、具有一或多個感測器1結合一或多個閘道器(gateway)2的環境，或是具有一或多個感測器1、一或多個路由器(router，圖未標示)及一或多個閘道器2的環境等，但不加以限定。

為便於理解，圖1以多個感測器1結合一個閘道器2的感測器無線傳訊為例，進行說明，但本發明的權利範圍並不以圖1所示的硬體架構為限。

於一實施例中，圖1的感測器1可以是用來偵測物理數值的實體感測器，例如可偵測用電量的電錶(Power Meter)、可偵測水管流量的流量計(Flow Meter)、可偵測物質存量的物液位計(Level Sensor)、瓦斯錶(Gas Sensor)、壓力錶(Pressure Transmitter)、水質感測器(Water Quality Sensor)、溫度計(Temperature Sensor)或熱影像裝置(Thermal Image Sensor)等，但不以此為限。具體來說，上列所謂的感測器1，是一種具有將物理性或化學性的變量，轉換成電子訊號的裝置實體。閘道器2可以是在感測器1內設置的電子傳輸模組或與感測器1分離獨立設置但電性連結具有閘道器功能的裝置實體，或是以獨立設置的物聯網(Internet of Things,IoT)設備實現的實體閘道器2，但不加以限定。

本發明中，閘道器2可以連接感測器無線傳訊中的一或多個感測器1，並且定期接收各個感測器1傳送的感測器資料。並且，閘道器2可定期將所搜集的感測器資料以無線傳輸的方式，上傳至指定的雲端伺服器，以利管理者基於各個感測器1的感測器資料進行後續的處理、運算與儲存。

本發明中的感測器1與閘道器2，主要指的是受約束(Constrained)的元件。意即，感測器1與閘道器2的硬體規格與處理能力較低，不具有傳統電腦(Personal Computer)或設備的作業系統(Operational System)能力，無法安裝各種資訊安全加解密的應用程式(例如防毒軟體、網頁瀏覽器)，也無使用者介面(Human Interface)做字元或密碼輸入。當感測器1與閘道器2進行通訊時，也無法採用與一般電腦設備相同的通訊協定(例如超文本傳輸協議(HyperText Transfer Protocol,HTTP)及傳輸控制協議(Transmission Control Protocol,TCP)等)來接入網際 網路並進行封包的傳輸。為了解決上述問題，本發明對受約束應用協議(Constrained Application Protocol,CoAP)進行改良，並基於CoAP令感測器1與閘道器2透過網際網路進行封包的傳輸。

CoAP是一種進行機器對機器(Machine to Machine)的數據交換時使用的協議，並且主要運作在物聯網中的小型設備的應用層(Application Layer)上。本發明將感測器1做為一種小型的物聯網設備，並基於CoAP來實現感測器1與閘道器2間的網路通訊。

若將感測器1做為CoAP的傳送端(Sender)，並將閘道器2做為CoAP的接收端(Recipient)，則當感測器1於應用層產生一個封包並且透過多個中間設備(例如路由器，圖未標示)將封包傳送至閘道器2時，這個封包可以直接在網路層(Network Layer)上被傳輸(例如透過IPv6)，而不需要返回每個中間設備的傳輸層(Transportation Layer)和應用層。如此一來，可以有效提高封包在感測器1與閘道器2之間的傳輸速度。

請同時參閱圖2，為本發明的加解密示意圖的具體實施例。如上所述，本發明主要是基於CoAP來實現感測器1與閘道器2間的網路通訊，並且為了確保通訊安全，本發明還基於CoAP的對象安全性(Object Security of CoAP,OSCoAP)執行對稱式加解密程序，以對所傳送的封包進行加密。

當感測器1做為傳送端並且閘道器2做為接收端時，感測器1基於特定規則產生傳送端加密鑰匙13以對資料進行加密，並且產生第一封包P1並發送至閘道器2。閘道器2接收第一封包P1後，基於特定規則產生接收端解密鑰匙24以對資料進行解密，藉此獲得資料內容。其中，感測器1產生的傳送端 加密鑰匙13與閘道器2產生的接收端解密鑰匙24為相同的鑰匙，而可符合OSCoAP採用的對稱式加解密規則。

相對地，當閘道器2做為傳送端並且感測器1做為接收端時，是由閘道器2基於特定規則產生傳送端加密鑰匙23以對資料進行加密，並且產生第二封包P2發送至感測器1。感測器1接收第二封包P2後，基於特定規則產生接收端解密鑰匙14以對資料進行解密，藉此獲得資料內容。於本實施例中，閘道器2產生的傳送端加密鑰匙23與感測器1產生的接收端解密鑰匙14亦為相同的鑰匙。

請同時參閱圖2及圖3，其中圖3為本發明的封包傳送流程圖的具體實施例。圖3揭露了本發明的封包加解密方法在傳送端方面的各個實施步驟。

如圖2所示，感測器1的記憶體(圖未標示，下稱為第一記憶體)中記錄了至少一筆第一安全上下文(Security Context)11，第一安全上下文11中記錄了共同內文(Common Context)111、傳送端ID(Sender ID)112及接收端ID(Recipient ID)113。本發明中，感測器1透過第一安全上下文11來計算所述傳送端加密鑰匙13與接收端解密鑰匙14。

於一實施例中，感測器1可於第一記憶體中記錄複數第一安全上下文11，並且各筆第一安全上下文11分別對應至不同的閘道器2。具體地，第一安全上下文11中的共同內文111為用來產生傳送端加密鑰匙13與接收端解密鑰匙14的主要資料，例如可記錄帶有關聯資料的認證加密演算法(Authenticated Encryption with Associated Data Algorithm,AEAD Algorithm)、主密鑰(Master Secret)及主鹽值(Master Salt)等資料，但不加以限定。

傳送端ID 112記錄了感測器1本身的ID資訊。接收端ID 113記錄了允許被傳送封包到此感測器1的閘道器2的ID資訊。當感測器1接收到一個閘道器2傳送過來的封包時，只有在這個閘道器2的ID資訊存在於任一個第一安全上下文11中(即，對應至任一個第一安全上下文11中的接收端ID 113)時，感測器1才會對這個封包進行處理(容後詳述)。

如圖2所示，閘道器2的記憶體(圖未標示，下稱為第二記憶體)中記錄了至少一筆第二安全上下文(Context)21，第二安全上下文21中記錄了共同內文211、傳送端ID 212及接收端ID 213。相似地，閘道器2可以透過第二安全上下文21來計算傳送端加密鑰匙23與接收端解密鑰匙24。並且，閘道器2同樣可於第二記憶體中記錄複數第二安全上下文21，並且令各筆第二安全上下文21分別對應至不同的感測器1。

本發明中，閘道器2的第二安全上下文21中的共同內文211與感測器1的第一安全上下文11中的共同內文111相同，因而閘道器2產生的傳送端加密鑰匙23與接收端解密鑰匙24可以與感測器1產生的接收端解密鑰匙14與傳送端加密鑰匙13互相對應。

閘道器2的傳送端ID 212記錄了閘道器2本身的ID資訊，而接收端ID 213則記錄了允許被傳送封包到這個閘道器2的感測器1的ID資訊。閘道器2接收到一個感測器1傳送過來的封包時，只有在這個感測器1的ID存在於任一個第二安全上下文21中(即，對應至任一個第二安全上下文21中的接收端ID 213)時，閘道器2才會對這個封包進行處理(容後詳述)。

透過在感測器1的第一記憶體以及閘道器2的第二記憶體中記錄第一安全上下文11與第二安全下上文21，感測器1和閘道器2可以直接產生加 密/解密用的鑰匙，而不需要為了執行完整的加解密程序而在不同層間進行交握(handshaking)。藉此，可以有效節省封包的傳輸時間。

為了便於理解，下面以將感測器無線傳訊中的感測器1做為CoAP的傳送端，並將感測器無線傳訊中的閘道器2做為CoAP的接收端為例，結合圖2及圖3進行本發明的封包加解密方法的詳細說明。

如圖3所示，在要進行資料的傳送時，感測器1首先從第一記憶體中讀取於應用層使用的第一安全上下文11(步驟S10)，並且從第一安全上下文11中取得共同內文111及傳送端ID 112(步驟S12)。本發明中，感測器1主要可基於共同內文111及傳送端ID 112(即，感測器1本身的ID)進行計算以產生傳送端加密鑰匙13。

值得一提的是，除非由使用者手動對感測器1進行修改，否則共同內文111與傳送端ID 112是固定的。雖然感測器1可以透過產生並使用傳送端加密鑰匙13來提高封包的安全性，但使用固定的共同內文111與傳送端ID 112來產生傳送端加密鑰匙13，就代表傳送端加密鑰匙13會是固定的。若持續使用固定的傳送端加密鑰匙13，將可能會導致鑰匙被破解而造成安全性下降。

於一實施例中，感測器1還可於要傳送資料時，依據特定規則來取得一個預設變數(步驟S14，Pre-determined Value)。於此實施例中，感測器1依據共同內文111、傳送端ID 112及預設變數來共同計算傳送端加密鑰匙13(步驟S16)。本發明中，所述預設變數是可變的。將預設變數做為傳送端加密鑰匙13的計算基礎，可以定期或不定期改變傳送端加密鑰匙13的內容，進而確保資料安全性。

本發明中，閘道器2必須與感測器1共享相同的特定規則，而可取得相同的預設變數。如此一來，閘道器2才能產生與所述傳送端加密鑰匙13相同的接收端解密鑰匙24，進而能實現對稱式解密程序。

於一實施例中，所述預設變數可例如為當前日期(例如年、月及日)。於此實施例中，感測器1與閘道器2每一天改變一次傳送端加密鑰匙13與接收端解密鑰匙24。於另一實施例中，所述預設變數可例如為當前時間。於此實施例中，感測器1與閘道器2每一小時改變一次傳送端加密鑰匙13與接收端解密鑰匙24。惟，上述僅為本發明的其中一種具體實施範例，但並不以上述者為限。

於產生了傳送端加密鑰匙13後，感測器1即可使用傳送端加密鑰匙13對要傳送的純文本(Plain Text)12進行加密，並產生密文(Cipher Text)(步驟S18)。接著，感測器1透過特定的標頭、傳送端ID 112及密文產生要傳送的封包，並將封包傳送至閘道器2(步驟S20)。當閘道器2接收到此封包時，可從封包中取得感測器1的傳送端ID 112，並且基於傳送端ID 112的相關資訊進行對稱式解密程序，以對封包中的密文進行解密並獲得所述純文本12。

請同時參閱圖4，為CoAP資料格式的示意圖的具體實施例。如圖4所示。CoAP的資料格式主要可包括版本編號(一般記錄為Ver)、訊息類型(一般記錄為T)、令牌長度(一般記錄為TKL(即Token Length))、要求碼/回覆碼(一般記錄為Code)、訊息識別碼(一般記錄為Message ID)、令牌(一般記錄為Token)、選項(一般記錄為Options)及酬載(一般記錄為Payload，其中包含酬載標誌)。其中，版本編號指出CoAP的版本號，訊息類型指出CoAP的形式(包括CON、NON、ACK或RST)，令牌用來將當下收到的回覆訊息匹配到先前送出 的一要求訊息，選項指出例如CoAP主機、埠號、資源路徑等資訊，酬載指出真正被交換的資料(例如上述的純文本12，但不加以限定)。

於一實施例中，感測器1主要是基於CoAP的資料格式，對酬載以及選項中的optionsClassE進行加密以產生密文，並且依據標頭、選項中的optionsClassI及optionsClassU、序列號15、傳送端ID 112及密文來產生封包。

惟，上述僅為本發明的其中一個具體實施範例，但並不以上述為限。

如前文所述，本發明中感測器1可做為CoAP的發送端，閘道器2可做為CoAP的接收端，藉此感測器1可基於CoAP來將封包傳送至閘道器2。

值得一提的是，當感測器1傳送封包至閘道器2時，有可能會傳送失敗，當封包傳送失敗時，感測器1就必須執行重送程序。然而在感測器1執行重送動作時，閘道器2有可能遭遇駭客的重送攻擊。為了防止駭客成功進行重送攻擊，本發明的封包中可添加可累計的序列號15，此序列號15可被用來判斷各個CoAP訊息在傳送端的產生順序。於上述圖3的步驟S18中，感測器1可基於標頭、傳送端ID 112、密文以及序列號15一同產生封包。

於一實施例中，序列號15為一個由0起算的整數。於第一次產生並傳送CoAP訊息時，序列號15的內容為0。若此CoAP訊息傳送失敗，則第二次產生並傳送CoAP訊息時，序列號15的內容維持為0。若第一次的CoAP訊息傳送成功，則於第二次產生並傳送CoAP訊息時，序列號15的內容更新為1，以此類推。於另一實施例中，感測器1還可同時基於序列號15來加密純文本12以產生密文，也就是說序列號15改變後，密文也會改變。

如圖2所示，在CoAP的架構下，做為接收端的閘道器2可具有重播窗口(Replay Window)25，重播窗口25用來基於封包中的序列號15驗證所接收的請求是否為舊的請求(容後詳述)。

如圖3所示，若於封包中使用序列號15，則於步驟S20後，感測器1可判斷封包是否傳送成功(步驟S22)。例如，感測器1可判斷是否收到閘道器2回傳的確認訊息。若封包傳送失敗(例如Timeout)，則感測器1直接取得同一個封包(例如暫存在記憶體中)，並且重送此封包至閘道器2(步驟S24)。此時，封包內的序列號15會維持相同。

於一實施例中，感測器無線傳訊可以預設有重送次數上限，例如為4次、10次等，不加以限定。當封包的傳送次數到達重送次數上限時，感測器1可認定此時網路環境很惡劣，據此停止傳送該封包，並且發出警示。

續請同時參閱圖2至圖5，其中圖5為本發明的封包接收流程圖的具體實施例。圖5揭露了本發明的封包加解密方法在接收端方面的各個實施步驟。

首先，閘道器2接收由感測器1傳送來的封包(步驟S30)。若封包中包含了所述序列號15，則閘道器2可從封包中取得序列號15，並且判斷是否已經接收過具有相同序列號15的封包(步驟S32)。若已經接收過具有相同序列號15的封包，代表此封包為舊的封包，此時閘道器2直接捨棄封包(步驟S46)，而不對封包進行處理。

具體地，閘道器2接收感測器1傳送的封包後，會透過重播窗口25從封包中取出序列號15，並基於序列號15判斷此封包是否為已經接收過的 封包。若封包中的序列號15與已經記錄的序列號15相同，閘道器2就可以認定此封包是已經接收過的舊封包，因而不處理這個封包。

一般來說，駭客從外部擷取了感測器1所傳送的封包後，若要進行重送攻擊，則需要先將序列號15加1後，再產生對應至更新後的序列號15的封包，並以此封包進行攻擊。然而，在沒有辦法產生傳送端加密鑰匙13的情況下，駭客難以通過上述程序來執行攻擊，故無法經由感測器1端，進行錯誤或有害的封包資料上傳。

另一方面，若駭客直接複製感測器1所傳送的封包，並且直接使用這個封包來進行重送攻擊，則當閘道器2接收此封包後，就會因為這個封包的序列號15指出這個封包是已經接收過的舊封包，而不對這個封包進行處理。如此一來，可以有效阻擋由駭客對接收端(此實施例中為閘道器2)發起的重送攻擊。

上述僅為本發明的其中一個具體實施範例，若感測器1產生的封包中不包含所述序列號15，則閘道器2不須執行上述步驟S32及步驟S46。意即，步驟S32及步驟S46非為本發明的必要技術特徵。

在接收了所述封包後，閘道器2從內部的第二記憶體中讀取於應用層使用的第二安全上下文21(步驟S34)，並且由第二安全上下文21中取得共同內文211，以及對應至封包中的傳送端ID 112的接收端ID 213。其中，所述接收端ID 213與封包中的傳送端ID 112相同，都是指向傳送此封包的感測器1本身的ID。

並且，閘道器2採用與感測器1相同的規則來取得預設變數(步驟S40)。例如，閘道器2可以取得當前日期或當前時間，以做為預設變數。藉 此，閘道器2可以依據共同內文211、接收端ID 213以及預設變數來產生接收端解密鑰匙24(步驟S42)。

由於閘道器2採用的共同內文211、接收端ID 213以及預設變數相等於感測器1採用的共同內文111、傳送端ID 112以及預設變數，因此閘道器2產生的接收端解密鑰匙24會相等於感測器1產生的傳送端加密鑰匙13。因此，閘道器2可以使用接收端解密鑰匙24解密封包中的密文，並獲得純文本12(步驟S44)。

值得一提的是，閘道器2中可於第二記憶體中記錄複數第二安全上下文21，其中各筆第二安全上下文21分別對應至不同的傳送端(例如，不同的感測器1)。

本實施例中，各筆第二安全上下文21分別記錄相同或不同的共同內文211、相同的傳送端ID 212以及不同的接收端ID 213。

傳送端ID 212為閘道器2本身的ID，用以在閘道器2做為傳送端而產生封包時，指出傳送端(即，閘道器2)的身份。

接收端ID 213用以指出閘道器2認可的傳送端(例如感測器1)的身份。本實施例中，閘道器2只有在內部記錄的多個接收端ID 213的其中之一與所接收的封包中記錄的傳送端ID 112相同時，才會對此封包進行處理。

共同內文211為用來產生對稱式金鑰的主要內容，並且與傳送端(例如感測器1)的第一安全上下文11中的共同內文111相互對應。本發明中，若閘道器2具有複數第二安全上下文21，則各筆第二安全上下文21中可記錄相同或不同的共同內文211。

於第一實施例中，所有感測器1的第一安全上下文11與閘道器2的所有第二安全上下文21可以皆記錄相同的共同內文111、211。

於另一實施例中，各個感測器1的第一安全上下文11中可分別記錄不同的共同內文111，而閘道器2的各筆第二安全上下文21中可分別記錄不同的共同內文211。

舉例來說，第一感測器X與閘道器2需要進行安全通訊，而第二感測器Y和閘道器2也需要進行安全通訊。於此實施例中，第一感測器X的第一安全上下文11中的共同內文111和閘道器2的第一筆第二安全上下文21裡的共同內文211相同(例如值為0xAAAABBBB)；第二感測器Y的第一安全上下文11中的共同內文111和閘道器2的第二筆第二安全上下文21裡的共同內文211相同(例如值為0xCCCCDDDD)。

於上述實施例中，第一感測器X的第一安全上下文11中的共同內文111(即，0xAAAABBBB)與第二感測器Y的第一安全上下文11中的共同內文111(即，0xCCCCDDDD)不同，而閘道器2的第一筆第二安全上下文21裡的共同內文211(即，0xAAAABBBB)與第二筆第二安全上下文21裡的共同內文211(即，0xCCCCDDDD)不同，但仍可適用本發明的加解密方法。

惟，上述僅為本發明的部分具體實施範例，但並不以上述為限。

如圖5所示，在接收感測器1傳送的封包後，閘道器2可從第二記憶體中依序讀取複數第二安全上下文21的其中之一(步驟S34)，並且判斷所讀取的第二安全上下文21中的接收端ID 213是否與封包中記錄的傳送端ID 112相同(步驟S36)。若複數第二安全上下文21的其中之一所記錄的接收端ID 213與此封包中記錄的傳送端ID 112相同，代表閘道器2被允許接收由這個感測器1所傳送的封包，因此閘道器2可接續執行步驟S40至步驟S44。

若於步驟S36中判斷目前讀取的第二安全上下文21中的接收端ID 213與封包中記錄的傳送端ID 112不同，則閘道器2接著判斷目前對於複數第二安全上下文21的巡訪動作是否結束(步驟S38)。意即，閘道器2判斷是否已將所有第二安全上下文21皆與封包進行了比對。並且，閘道器2在完成巡訪動作前，重覆執行步驟S34及步驟S36。

若於巡訪動作完成後，都沒有找到與封包中記錄的傳送端ID 112相同的接收端ID 213，就代表傳送這個封包的感測器1不在閘道器2的白名單中。此時，閘道器2不對這個封包進行處理。

請同時參閱圖2至圖6，其中圖6為本發明的封包接收流程圖的具體實施例。

如圖6所示，當閘道器2接收一個封包並且取得封包中的傳送端ID 112後，會先從第二記憶體中取得複數第二安全上下文21中的第一筆第二安全上下文201，並將此第二安全上下文201中的接收端ID 213與封包中的傳送端ID 112進行比對。若比對不相符，閘道器2接著取得複數第二安全上下文21中的第二筆第二安全上下文202，並將此第二安全上下文202中的接收端ID 213與封包中的傳送端ID 112進行比對。

承上，若比對仍不相符，閘道器2接著取得複數第二安全上下文21中的第三筆第二安全上下文203，並將此第二安全上下文203中的接收端ID 213與封包中的傳送端ID 112進行比對，以此類推。當確定任一筆第二安全上 下文21的接收端ID 213與封包中的傳送端ID 112相符時，閘道器2停止讀取下一筆第二安全上下文21。

透過上述巡訪動作，閘道器2可以判斷封包的傳送端(本實施例中為感測器1)是否存在白名單，進而決定是否要對封包進行處理。

於上述對於圖3及圖5的說明中，是以將感測器1做為CoAP的傳送端，並將閘道器2做為CoAP的接收端的感測器無線傳訊為例。然而，本發明同樣可應用在以將閘道器2做為CoAP的傳送端，並將感測器1做為CoAP的接收端的感測器無線傳訊中。

以圖2為例，當閘道器2要傳送封包到感測器1時，閘道器2可讀取第二記憶體中的第二安全上下文21以獲得共同內文211及傳送端ID 212(即，閘道器2本身的ID)，並且依據與感測器1相同的規則取得預設參數。藉此，閘道器2可依據共同內文211、傳送端ID 212及預設變數來產生傳送端加密鑰匙23。

於產生了傳送端加密鑰匙23後，閘道器2可使用傳送端加密鑰匙23對要傳送的純文本22進行加密以產生密文，再透過標頭、傳送端ID 212、序列號(若存在)及密文產生要傳送的封包，並將封包傳送感測器1。

感測器1接收閘道器2傳送的封包後，可透過封包的序列號15(若存在)判斷是否要對封包進行處理。若要處理此封包，則感測器1從內部的第一記憶體中依序讀取複數第一安全上下文11的其中之一，並判斷是存在與封包中記錄的傳送端ID 212相符的接收端ID 113。若複數第一安全上下文11中存在與封包中記錄的傳送端ID 212相符的接收端ID 113，代表感測器1被允許接收並處理這個閘道器2所傳送的封包。

據此，感測器1從這個第一安全上下文11中取出共同內文111及接收端ID 113，並且採用與閘道器2相同的規則獲得預設變數，並且再依據共同內文111、接收端ID 113以及預設變數產生接收端解密鑰匙14。藉此，感測器1可以使用接收端解密鑰匙14對封包中的密文進行解密，以獲得純文本22。

透過本發明的上述技術方案，感測器無線傳訊中的感測器1與閘道器2可以基於CoAP來提高封包傳送速度，並且基於OSCoAP來提高通訊安全性。並且，本發明中的傳送端加密鑰匙13、23與接收端解密鑰匙14、24為針對OSCoAP的加密鑰匙與解密鑰匙。

閘道器2的硬體資源相當有限，並且僅具有很小的儲存能力。在持續接收感測器1的資料後，閘道器2需要定期將資料上傳至有較大儲存能力的雲端伺服器進行保存。

一般來說，企業可以依據實際需求來選用適合的雲端伺服，例如可以租用亞馬遜公司(Amazon)提供的Amazon Web Services(AWS)、微軟公司(Microsoft)提供的Azure或谷歌公司(Google)提供的Google Cloud Platform等，但不以此為限。然而，這些雲端伺服器的收費政策可能是浮動的，當發現其他雲端伺服器的收費較便宜時，企業可能會想要更換當前使用的雲端伺服器並使用其他雲端伺服器。再者，企業可能會在一個雲端伺服器中啟用多個執行個體(instance)，當原本使用的執行個體需要暫時停止服務時，企業同樣需要將資料轉存至其他的執行個體中。

不同的雲端伺服器或是不同的執行個體都需使用不同的IP Address來連接，因此企業要更換雲端伺服器或是執行個體時，通常需要以人工 方式來重新設定所有的閘道器2，不但需要相當高昂的人力成本，亦相當耗時。並且，此種手動更新的方式容易產生部分閘道器2已更新，但部分閘道器2仍將資料上傳至舊的雲端伺服器或舊的執行個體，而造成資料不同步問題。

有鑑於上述問題，本發明進一步提出在感測器無線傳訊中使用的雲端伺服器自動識別方法。

請同時參閱圖7及圖8，其中圖7為本發明的感測器無線傳訊的示意圖的第二具體實施例，圖8為本發明的資料上傳流程圖的具體實施例。

如圖7及圖8所示，閘道器2可內建有一份配置檔20，配置檔20中記錄有閘道器2當前的上傳目的地的位址資訊，所述上傳目的地即為企業當前使用的雲端伺服器(例如圖7中的第一雲端伺服器31)。當閘道器2要將所搜集的資料上傳至雲端伺服器時，首先讀取內部的配置檔20以取得第一雲端伺服器31的位址資訊(步驟S50)，接著基於CoAP指令將資料上傳至使用這個位址資訊的第一雲端伺服器31(步驟S52)。於一實施例中，所述CoAP指令可例如為coap.put(指令)，但不以此為限。

接著，閘道器2判斷資料是否上傳成功(步驟S54)。若資料上傳成功，代表閘道器2的上傳目的地沒有變更，因此閘道器2可直接結束本次上傳動作。於一實施例中，閘道器2判斷是否接收第一雲端伺服器31回覆的確認訊息(例如為coap ACK)，以判斷資料是否上傳成功。

若資料上傳失敗，閘道器2進一步確認資料的上傳次數是否到達預設的重送次數上限(步驟S56)。於一實施例中，所述重送次數上限可例如為四次、八次、十次等，不加以限定。若資料上傳失敗，但上傳次數尚未到達重送次 數上限，閘道器2可以再次執行步驟S52，以重新上傳相同資料到第一雲端伺服器31。

若資料上傳失敗，且上傳次數已經到達重送次數上限，代表閘道器2的上傳目的地已經變更。此時，閘道器2可基於CoAP指令向資料伺服器32發送位址詢問請求(步驟S58)，並且再接收資料伺服器32所回覆的位址資訊(步驟S60)。上述CoAP指令可例如為coap.get( )指令，但不以此為限。其中，資料伺服器32所回覆的位址資訊，即為變更後的新雲端伺服器所使用的位址資訊。

所述資料伺服器32可由企業人員建置並且管理。本發明中，當企業因為價格、速率或其他考量而更換閘道器2的上傳目的地後，可以將新上傳目的地(例如圖7中的第二雲端伺服器33)的位址資訊記錄在資料伺服器32中。感測器無線傳訊中的所有閘道器2皆可詢問資料伺服器32來取得新上傳目的地的位址資訊。藉此，企業只需要對資料伺服器32進行一次的修改動作，就可以完成對感測器無線傳訊中的所有閘道器2的更新動作，達到快速、低成本且減少人力資源的目的。

於一實施例中，閘道器2亦可不需要記錄所述配置檔20。於此實施例中，閘道器2可以在需要上傳資料到上傳目的地時，先對資料伺服器32發送位址詢問請求，並且從資料伺服器32處取得上傳目的地的位址資訊。換句話說，閘道器2不以具備所述配置檔20為必要。

於步驟S60後，閘道器2可使用資料伺服器32提供的位址資訊來更新配置檔20(步驟S62)，意即，以第二雲端伺服器33的位址資訊來取代第一雲端伺服器31的位址資訊。而在步驟S62後，閘道器2即可透過與上述相同的 程序，從配置檔20中讀取第二雲端伺服器33的位址資訊，並且基於CoAP指令(例如coap.put( ))來將資料上傳至第二雲端服器33。

如上所述，本發明讓閘道器2在上傳失敗時自動詢問資料伺服器32，以取得新雲端伺服器的位址資訊。藉此，可由閘道器2自動執行上傳目的地的更新動作，進而能以最低的成本及最快的速度來完成雲端伺服器的搬移。

以上所述僅為本發明之較佳具體實例，非因此即侷限本發明之專利範圍，故舉凡運用本發明內容所為之等效變化，均同理皆包含於本發明之範圍內，合予陳明。

1:感測器

11:第一安全上下文

111:共同內文

112:傳送端ID

113:接收端ID

12:純文本

13:傳送端加密鑰匙

14:接收端解密鑰匙

15:序列號

2:閘道器

21:第二安全上下文

211:共同內文

212:傳送端ID

213:接收端ID

22:純文本

23:傳送端加密鑰匙

24:接收端解密鑰匙

25:重播窗口

P1:第一封包

P2:第二封包

Claims (10)

1. 一種感測器無線傳訊的封包加解密方法，應用於具有一感測器以及一閘道器的一感測器無線傳訊，其中該感測器基於受約束的應用協議(Constrained Application Protocol,CoAP)傳送封包，該感測器為CoAP的發送端(Sender)，該閘道器為CoAP的接收端(Recipient)，包括：a)該感測器從一第一記憶體中讀取於應用層使用的一第一安全上下文；b)由該第一安全上下文中取得一共同內文及一傳送端ID，其中該傳送端ID為該感測器的ID；c)取得一預設變數；d)依據該共同內文、該傳送端ID及該預設變數產生一傳送端加密鑰匙；e)以該傳送端加密鑰匙加密一純文本並產生一密文；f)依據一標頭、該傳送端ID、該密文及一序列號產生一封包並傳送至該閘道器，其中該序列號指出該封包的傳送次數，該閘道器基於該傳送端ID的相關資訊解密該密文並取得該純文本，其中該閘道器具有一第二安全上下文，該第二安全上下文中包含一接收端ID，該接收端ID指出該閘道器認可的感測器的ID資訊，並且該閘道器僅於該封包中的該傳送端ID對應至該第二安全上下文中的該接收端ID時對該封包進行處理。
2. 如請求項1所述的感測器無線傳訊的封包加解密方法，其中該預設變數為當前日期。
3. 如請求項1所述的感測器無線傳訊的封包加解密方法，其中該共同內文至少記錄帶有關聯資料的認證加密演算法(Authenticated Encryption with Associated Data Algorithm,AEAD Algorithm)、主密鑰(Master Secret)及主鹽值(Master Salt)。
4. 如請求項1所述的感測器無線傳訊的封包加解密方法，其中更包括：f1)於步驟f)後，判斷該封包是否傳送成功；及f2)於該封包傳送失敗時將該序列號加1並產生一更新後序列號，並且依據該更新後序列號再次執行該步驟f)。
5. 如請求項1所述的感測器無線傳訊的封包加解密方法，其中更包括：g)該閘道器接收該封包；h)由該封包中取得該序列號，並且判斷是否已經接收過具有該序列號的該封包；及i)於已經接收過具有該序列號的該封包時，直接捨棄該封包。
6. 如請求項1所述的感測器無線傳訊的封包加解密方法，其中更包括：j)該閘道器接收該封包；k)從一第二記憶體中讀取於應用層使用的該第二安全上下文；l)由該第二安全上下文中取得該共同內文及對應至該傳送端ID的該接收端ID，其中該接收端ID為該感測器的ID；m)取得該預設變數，其中該閘道器與該感測器透過相同規則取得該預設變數； n)該閘道器依據該共同內文、該接收端ID及該預設變數產生一接收端解密鑰匙；及o)以該接收端解密鑰匙解密該密文並取得該純文本。
7. 如請求項6所述的感測器無線傳訊的封包加解密方法，其中該第二記憶體中記錄複數該第二安全上下文，各該第二安全上下文分別對應至不同感測器，並且該步驟k)包括：k1)從該第二記憶體中讀取該複數第二安全上下文的其中之一；k2)判斷所讀取的該第二安全上下文中的該接收端ID是否相同於該封包的該傳送端ID；k3)於所讀取的該第二安全上下文中的該接收端ID不同於該封包的該傳送端ID，但該複數第二安全上下文尚未全部讀取完畢時，再次執行該步驟k1)及該步驟k2)；及k4)於所讀取的該第二安全上下文中的該接收端ID相同於該封包的該傳送端ID時，執行該步驟1)。
8. 如請求項6所述的感測器無線傳訊的封包加解密方法，其中該傳送端加密鑰匙與該接收端解密鑰匙為針對CoAP的對象安全性(Object Security of CoAP,OSCoAP)的加密鑰匙與解密鑰匙。
9. 如請求項6所述的感測器無線傳訊的封包加解密方法，其中更包括：p)該閘道器基於一第一CoAP指令將一資料上傳至一第一雲端伺服器；q)於該資料上傳失敗但尚未到達一重送次數上限時，再次執行該步驟p)； r)於該資料上傳失敗且到達該重送次數上限時，基於一第二CoAP指令向一資訊伺服器發送一位址詢問請求；s)該步驟r)後，接收該資訊伺服器發送的一位址資訊，其中該位址資訊指出用以取代該第一雲端伺服器的一第二雲端伺服器；及t)該步驟s)後，基於該第一CoAP指令將該資料上傳至該第二雲端伺服器。
10. 如請求項9所述的感測器無線傳訊的封包加解密方法，其中該閘道器具有一配置檔，該配置檔記錄該第一雲端伺服器的一位址資訊，該步驟p)包括讀取該配置檔以取得該第一雲端伺服器的該位址資訊，該步驟s)包括使用該第二雲端伺服器的該位址資訊更新該配置檔，並且該步驟t)包括讀取更新後的該配置檔以取得該第二雲端伺服器的該位址資訊。

Images