用於建立端到端的安全連接和用於安全地傳送數據分組的方法、設備以及系統的製作方法

2023-08-10 12:28:21

用於建立端到端的安全連接和用於安全地傳送數據分組的方法、設備以及系統的製作方法
【專利摘要】本發明提供了用於建立端到端的安全連接和用於安全地傳送數據分組的方法、設備(102,110,124,136)以及通信系統(100)。這樣的通信系統(100)包括第一設備(124,136)、中間設備(110)以及第二設備(102)。所述第一設備(124,136)經由第一網絡(120)與所述中間設備(110)進行通信，所述第一網絡(120)是基於第一傳輸協議和第一傳輸安全協議的。所述第二設備(102)經由第二網絡與所述中間設備(110)進行通信，所述第二網絡是基於第二傳輸協議和第二傳輸安全協議的。所述中間設備(110)將經由第一網絡接收到的分組修改為適合於經由所述第二網絡傳送的分組，並且反之亦然。所述第一設備(124，136)能夠重建接收到的分組的頭部，好像所述分組是經由所述第二網絡(108)及其傳輸和安全協議被發送的。進一步地，所述第一設備(124)能夠在經重建的頭部的基礎上來驗證在所述第二傳輸安全協議的基礎上被生成的驗證欄位。
【專利說明】用於建立端到端的安全連接和用於安全地傳送數據分組的方法、設備以及系統
【技術領域】
[0001]本發明涉及用於在其中多個安全協議正被使用的情形中建立端到端的安全連接的方法、設備以及系統，所述安全協議諸如例如傳輸層安全協議(TLS)和數據報傳輸層安全協議(DTLS)。
【背景技術】
[0002]物聯網(1T)表示遵循許多通信模式的網絡和高度異構的聯網實體的互連，所述通信模式諸如:人對人(H2H)、人對物(H2T)、物對物(T2T)或物對多物(T2Ts)。術語1T首先被Auto-1D中心在1999年杜撰。從那時起，底層概念的發展曾加大其步伐。現今，1T呈現了對具有各種首創精神的研究的強烈聚焦，所述各種首創精神致力於標準網際網路技術在1T中的(再)設計、應用以及使用。
[0003]IPv6和web服務作為針對1T應用的基本結構單兀(fundamental buildingblock)的引入承諾帶來許多基本優點，包括:(i)允許與網際網路主機的簡單集成的同質(homogeneous)協議生態系統；(ii)非常不同的器具的簡化開發；(iii)針對應用的統一接口，從而去除對應用層代理的需要。這種特徵大大地簡化了範圍從建築自動化到生產環境至個人區域網的所設想的場景的部署，其中諸如溫度傳感器、照明器或RFID標籤之類的非常不同的事物可能與彼此、與攜帶智慧型電話的人或者與後端服務交互。
[0004]在這個設定(setting)中，許多IETF工作組正在為智能事物的資源受限網絡設計新的協議。6LoWPAN工作組專注於針對IPv6分組在IEEE 802.15.4網絡上的高效傳輸和適應的方法和協議的定義。CoRE工作組為旨在在受限IP網絡^LoWPAN)上運行的面向資源的應用提供框架。其主要任務之一是定義HTTP協議的輕量級版本，即受限應用協議(CoAP)，其在UDP上運行並且針對事物使能實現高效應用層通信。
[0005]這些新的協議將使能實現包括建築自動化控制(BAC)、健康監視、智能能源等的許多不同的應用。在這個設定中，形成6LoWPAN/CoAP網絡的終端設備(諸如致動器(actuators)或傳感器)將被用於物理參數和器具的實時監視或控制。在BAC的情況下，致動器可能是照明器和傳感器，光傳感器和照明器可能訪問適配其光設定的光傳感器的資源。另一場景指的是其中位於後端中(即，在6LoWPAN/CoAP網絡外)的CoAP設備(例如，客戶端)通過將網際網路與6LoWPAN/CoAP網絡互連的6LoWPAN邊界路由器(6LBR)來訪問6LoWPAN/CoAP網絡中的設備(例如，CoAP伺服器)的資源的場景。這樣的訪問能夠被需要來獲得特定資源或者將某種特定配置從後端推送到6LoWPAN/CoAP網絡中的CoAP設備。
[0006]安全對於上述應用區域和用例來說是關鍵方面。安全的特定目標是提供兩個設備之間的諸如機密性、認證或新鮮感之類的基本安全服務。在使用對稱密鑰密碼術的情況下，這對設備共享在用於相互認證的共同握手和秘密會話密鑰的導出期間被使用的公共主密鑰。這個會話密鑰連同密碼套件(cipher suite)—起被用來在兩個設備之間的信息交換中提供上述安全服務。類似握手還能夠藉助於不對稱密鑰密碼術被執行。[0007]在IP協議的情況下，存在包括TLS或DTLS的不同安全協議。TLS被用來保護運行在傳輸控制協議(TCP)之上的應用層上的協議。DTLS是用來保護運行在UDP上的應用的它的擴展。CoAP將DTLS標識為保護CoAP通信的交換的強制性方法，然而大多數安裝的基礎伺服器使用例如被與TCP和TLS相結合地使用的超文本傳送協議(HTTP)代替CoAP。
[0008]在上述設定中，安全的端到端連接的提供是有挑戰性的。原因之一是6LoWPAN邊界路由器或代理^LBR)應該能夠驗證在兩個設備之間的所交換的請求是否位於6LoWPAN/CoAP網絡外部和內部。當例如公用事業公司的CoAP客戶端將請求發送到CoAP伺服器(例如，智能儀表)時這個發生。6LBR必須能夠驗證來自客戶端的請求是有效的以便防止例如能源耗盡攻擊(或者限制其影響)。另一非常有趣的情形指的是舊設備在後端中的存在，所述舊設備例如是應該能夠訪問在6LoWPAN/CoAP網絡中的終端設備中的信息的HTTP設備。在這種情形下，在例如後端中的HTTP客戶端與6LoWPAN/CoAP網絡中的CoAP伺服器之間建立安全的端到端連接由於正被使用的多種多樣的密鑰交換機制而仍然是一個挑戰，即在舊系統中的TLS (基於TCP的)被使用，而受限的6L0WPAN網絡僅支持DTLS (基於UDP的)。這是更複雜的，因為6LoWPAN/CoAP網絡中的CoAP設備不知道密鑰建立請求正來自哪裡。
[0009]對於特定情形來說，端到端連通性是必須的事情，例如軟體更新、網絡準入、記費等。在這種情形下，端到端握手是需要的。在網際網路上，舊系統僅支持在TCP上的HTTP，以及用於安全連接的TLS。因此在這裡所討論的特定情形能夠被描繪如下:網際網路上的HTTP設備使用HTTP來直接地從CoAP設備訪問資源。協議轉換通過存在於它們之間的HTTP/CoAP代理來完成。在這個情形下的目標是確保HTTP設備能夠具有使用TLS的安全的端到端通信，並且CoAP設備能夠建立使用DTLS的安全的端到端通信。
[0010]TCP是提供可靠通信的面向連接的協議。然而，UDP不是面向連接的並且不確保分組遞送。如上面所陳述的那樣 ，DTLS是用來在UDP之上運行從而克服UDP的局限性的TLS的擴展。在兩種情況下，TLS和DTLS的初始握手包括4組消息在客戶端與伺服器之間的交換。在下面我們討論了最小握手。注意，每個步驟指的是許多消息從第一設備(例如，客戶端)到第二設備(例如，伺服器)的發送。
[0011]步驟I (從客戶端到伺服器):Client Hello (客戶端問候)
步驟2 (從伺服器到客戶端):Server Hello (伺服器問候)；ServerHelloDone (伺服器問候完成)
步驟3 (從客戶端到伺服器):ClientKeyExchange (客戶端密鑰交換)；ChangeCipherSpec (改變密碼規格)；完成(Finished)
步驟4 (從伺服器到客戶端):ChangeCipherSpec,完成
儘管DTLS是基於TLS的並且以上消息保持相同，但是存在使協議彼此不可互操作的較小差異。差異中的一些是:
-cookie機制在DTLS中能夠被用來驗證發起請求的客戶端的存在。在TLS中，這樣的cookie機制不是需要的，因為TCP三向握手確定客戶端的存在。
-DTLS結合附加的欄位以便提供用於在UDP上運行DTLS的所需的可靠性。在TLS中，底層的TCP層提供所需可靠性以便那些欄位不是需要的。
-DTLS在初始握手期間依賴重傳機制來確保由第一設備所發送的消息被第二設備接收。TLS不需要這樣的方法，因為可靠傳輸通過TCP而被確保。
【發明內容】

[0012]因此，本發明的目標是提供在作為約束網絡的一部分的受限設備中所需要的邏輯以便允許受限設備與不運行受限應用協議的其它設備建立安全的端到端連接。修改非受限設備以便建立端到端的安全連接不是優選的，並且改變現有安全協議不是優選的。進一步地，在受限設備中創建大量開銷也不是優選的。
[0013]本發明的第一方面提供了用於在第一設備與第二設備之間安全地傳送數據分組的兩個通信系統。本發明的第二方面提供了用於在本發明的第一方面的通信系統中使用的兩個設備。本發明的第三方面提供了用於在本發明的第一方面的通信系統中使用的中間設備。本發明的第四方面提供了用於在第一設備與第二設備之間安全地傳送數據分組的兩個方法。有利的實施例在從屬權利要求中被定義。
[0014]依據本發明的第一方面的通信系統是用於在第一設備與第二設備之間安全地傳送數據分組的。所述通信系統包括第一網絡、第一設備、第二網絡、第二設備以及中間設備。第一網絡是基於第一傳輸協議的。第一設備經由第一網絡與其它設備進行通信並且在第一傳輸協議之上應用第一傳輸安全協議。第二網絡是基於第二傳輸協議的。第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議。第二設備經由第二網絡與其它設備進行通信並且第二設備在第二傳輸協議之上應用第二傳輸安全協議。中間設備經由第一網絡與第一設備進行通信並且經由第二網絡與第二設備進行通信。中間設備將依據第一傳輸安全協議被生成的經由第一網絡接收到的數據分組修改成用於依據第二傳輸安全協議經由第二網絡傳送的數據分組，並且反之亦然。因此，經由第二網絡接收到的數據分組同樣被修改成適合於經由第一網絡傳送的分組。第一設備重建從中間設備接收到的第一數據分組的頭部，使得所述頭部對應於第二分組的頭部，所述第二分組被第二設備傳送到中間設備並且被中間設備修改為第一數據分組。第一設備在經重建的第一數據分組的頭部的基礎上來驗證接收到的數據分組的安全驗證欄位。驗證欄位是由第二設備依據第二傳輸安全協議生成的。應指出，所接收到的數據分組(其安全驗證欄位被驗證)可以是其頭部被重建的第一數據分組，或者是以後被接收的另一數據分組。
[0015]本發明的解決方案與在系統中採取的兩個措施相關。中間設備將數據分組從在第一網絡上使用的格式改變為在第二網絡上使用的格式。常常，這僅包括對分組的頭部的改變，並且可以包括與第一傳輸安全協議的信息和/或第二傳輸安全協議的信息相關的改變。應指出，在中間設備將數據分組從在第一網絡上使用的格式改變為在第二網絡上使用的格式時，數據分組有效載荷在大多數情況下是不變的。隨後，當原始頭部經由第二網絡被中間設備接收到時，第一設備能夠重建原始頭部(因此，所述頭部在其被改變為適合於在第一網絡上傳送的格式之前被中間設備接收到)。隨後，第一設備能夠在經重建的頭部的基礎上來驗證接收到的數據分組的驗證欄位。所接收到的驗證欄位是由第二設備在第二傳輸安全協議的基礎上生成的。常常，驗證欄位的生成包括(哈希)函數的使用，所述(哈希)函數使用一個或多個數據分組頭部和/或數據分組有效載荷作為輸入。因此，被用來生成驗證欄位的頭部還必須在用於對驗證欄位進行驗證的驗證設備處是可用的。頭部的重建保證這些頭部的可用性。[0016]在特定傳輸安全協議中，端到端連接能夠僅在設備中的至少一個能夠驗證驗證欄位時被建立。因此，本發明提供了建立安全的端到端連接的可能性，因為在第一傳輸安全協議中與在第二傳輸協議中的差異被克服了。在特定傳輸安全協議中，一旦安全連接被建立了，驗證欄位就仍然被用來驗證所接收到的數據分組的真實性，並且本發明提供了這樣做的裝置。
[0017]根據本發明的第一方面，在第二設備中不需要改變。進一步地，儘管中間設備必須完成從第一傳輸安全協議到第二傳輸安全協議的一些轉化，但是中間設備未積極地牽涉到安全的端到端連接的建立中並且未積極地牽涉到信息的驗證中。這意味著，在其中終端設備具有專用的、預共享密鑰的傳輸安全協議中，中間設備不具有這個密鑰的知識，因為它未積極地牽涉到執行傳輸安全協議中。
[0018]應指出，安全驗證欄位的驗證在經重建的數據分組的頭部的基礎上被執行。「基於」不意味著它被限於在經重建的數據分組的頭部的基礎上的驗證，所述驗證可以考慮其它數據，例如數據分組的有效載荷。
[0019]可選地，第一傳輸安全協議和第二傳輸安全協議用握手協議發起安全通信會話。包括驗證欄位的所接收到的數據分組是握手協議的數據分組。因此，握手協議規定了包括驗證欄位的數據分組的交換。本發明允許驗證欄位的驗證，並且因此，允許握手協議的執行。常常，像在傳輸層安全(TLS)或數據報傳輸層安全(DTLS)中一樣,完成消息必須在握手結束時被發送並且握手包括為同樣基於在握手期間發送的有效載荷和分組頭部的驗證碼。在這種情況下，根據本發明，分組頭部能夠在第一設備處被重建，並且完成消息能夠根據需要通過由第二設備所使用的協議而被驗證。
[0020]可選地，所接收到的分組包括消息認證碼作為用於對所接收到的數據分組的真實性進行認證的安全驗證欄位。在數個傳輸安全協議中，消息認證碼的使用對於在建立的端到端的安全連接上傳送的消息來說是強制性的以便能夠驗證消息的真實性。消息認證碼常常是基於數據分組在該數據分組的傳輸時刻的頭部和有效載荷的。像在本發明的系統中那樣，如果數據分組被中間設備修改以用於沿著具有另一傳輸安全協議的另一網絡傳輸，則所述數據分組的頭部的內容可以被改變，並且因此，必須被重建以便驗證消息驗證碼。
[0021]可選地，第一設備首先依據第一傳輸安全協議來驗證安全驗證碼，並且如果這個驗證是不成功的，則第一數據分組的頭部被重建並且安全驗證欄位依據第二傳輸安全協議在經重建的第一數據分組的頭部的基礎上被驗證。因此，第一設備被配置成應用試錯(trail and error)方法。第一設備在第一傳輸安全協議的基礎上來預期驗證碼,並且因此，首先設法相應地驗證所述驗證碼。如果這是成功的，則驗證碼顯然是被從也使用第一傳輸安全協議的設備接收的。如果這是不成功的，則頭部被重建，並且如果根據第二傳輸安全協議的驗證在頭部的重建之後是成功的，則數據分組原先是使用第二傳輸安全協議的設備被發送的。因此，最初第一設備不需要具有關於另一個設備的知識。第一設備能夠找出哪一個傳輸安全協議被使用了。在根據這個可選實施例的驗證之後，第一設備還具有了從特定設備接收到的數據分組是根據特定傳輸安全協議被發送的知識。這個知識能夠被用在將來的嘗試中以便驗證所述驗證碼，使得不必要的「試錯」步驟被防止。
[0022]根據本發明的第一方面，用於在第一設備與第二設備之間安全地傳送數據分組的另外的通信系統被提供。所述通信系統包括第一網絡、第一設備、第二網絡、第二設備以及中間設備。第一網絡是基於第一傳輸協議的。第一設備經由第一網絡與其它設備進行通信並且在第一傳輸協議之上應用第一傳輸安全協議。第二網絡是基於第二傳輸協議的。第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議。第二設備經由第二網絡與其它設備進行通信並且在第二傳輸協議之上應用第二傳輸安全協議。中間設備經由第一網絡與第一設備進行通信並且經由第二網絡與第二設備進行通信。中間設備將依據第一傳輸安全協議被生成的經由第一網絡接收到的數據分組修改成用於依據第二傳輸安全協議經由第二網絡傳送的數據分組，並且反之亦然。因此，經由第二網絡接收到的數據分組同樣被修改成適合於經由第一網絡傳送的分組。第一設備重建從中間設備接收到的第一數據分組的頭部，使得所述頭部對應於第二分組的頭部，所述第二分組被第二設備傳送到中間設備並且被中間設備修改為第一數據分組。第一設備為要被發送的第三數據分組生成安全驗證欄位。所述安全驗證欄位在經重建的第一數據分組的頭部的基礎上被生成並且依據第二傳輸安全協議被生成。
[0023]依據本發明的第一方面的這個另外的通信系統強烈地與較早地討論的通信系統相關。較早地討論的通信系統定義第一設備能夠驗證依據本發明的第二方面被生成的驗證欄位，另外的通信系統定義第一設備能夠依據本發明的第二方面來生成驗證欄位。因此，在根據本發明的第一方面的系統中的一個中，第一設備是客戶端並且第二設備是伺服器，在系統中的另一個中，角色被顛倒。因此，換句話說，如果本發明的兩個方面被組合在單個系統中，則第一設備完全能夠在第一設備的所有可能的(客戶端/伺服器)角色中安全地與應用第二傳輸安全協議的第二設備進行通信。
[0024]可選地，第一傳輸安全協議和第二傳輸安全協議用握手協議發起安全通信會話。要被發送的第三數據分組是握手協議的數據分組。如在另一可選實施例處所討論的那樣，握手協議常常包括完成消息，所述完成消息包括基於數據分組的一個或多個頭部和有效載荷的驗證碼。這個可選實施例給第一設備提供生成具有依據第二傳輸安全協議的驗證碼的這種完成消息的能力。並且，因此，第二設備能夠在沒有關於第一傳輸安全協議的知識的情況下驗證這種完成消息。
[0025]可選地，第一設備發送包括依據第一傳輸安全協議生成的安全驗證欄位的第四數據分組並且發送包括依據第二傳輸安全協議生成的安全欄位的第三數據分組。因此，第一設備通過發送兩個不同的數據分組來應用「試錯方法」，其中，一個數據分組包括依據第一傳輸安全協議的驗證碼並且另一個數據分組包括依據第二傳輸安全協議的驗證碼。在可選的實際實施例中，具有依據第一傳輸安全協議的驗證碼的第四分組被首先發送，並且如果安全通信的積極延續未被檢測到，則具有依據第二傳輸安全協議的驗證碼的第三分組隨後被發送。安全通信的非積極延續意味著另一個設備很可能不能夠理解第一傳輸安全協議的驗證欄位，並且因此，很可能能夠理解第二傳輸安全協議的驗證欄位。
[0026]可選地，第一設備檢測它是否與應用第二傳輸安全協議的另一設備進行通信。如果第一設備檢測到它與應用第二傳輸安全協議的另一設備進行通信，則第一設備被配置成發送包括依據第二傳輸安全協議生成的安全欄位的第三數據分組。關於另一設備的知識允許第一設備立即發送包括依據被另一設備所理解的傳輸安全協議的驗證碼的數據分組。這提高了效率。另一設備是應用第一傳輸安全協議或第二傳輸安全協議的檢測可以是基於試錯傳輸和/或生成或接收到的驗證欄位的驗證的，諸如之前在兩個可選實施例中所描述的那樣。
[0027]可選地,第一網絡傳輸通信協議是基於網際協議(Internet Protocol)的用戶數據報協議，第二網絡傳輸通信協議是基於網際協議的傳輸控制協議，第一傳輸安全協議是數據報傳輸層安全協議，並且第二傳輸安全協議是傳輸層安全協議。特別地，傳輸層安全(TLS)協議在第二網絡中的使用與數據報傳輸層安全(DTLS)協議在第一網絡中的組合是有利的，因為與依據TLS被發送的數據分組相比，依據DTLS被發送的數據分組的頭部包括幾個附加的欄位。因此，如果分組被從第二網絡接收，則中間設備必須僅生成附加的欄位，並且如果分組被從第一網絡接到，則中間設備必須僅刪除附加的欄位。特別地，附加的欄位的生成是能夠容易地被第一設備顛倒的操作，並且因此，通過第一設備進行的頭部的重建是相對簡單的操作，其不需要關於第二網絡、第二網絡傳輸協議、第二傳輸安全協議或第二設備的更多知識。
[0028]可選地，第一設備被配置成應用受限應用協議並且第二設備被配置成應用超文本傳送協議。
[0029]根據本發明的第三方面，第一設備被提供用於在根據本發明的第一方面的通信系統中使用。第一設備包括第一網絡接口、第一安全協議應用裝置、重建器以及驗證器。第一網絡接口經由第一網絡與其它設備進行通信。第一網絡是基於第一傳輸協議的，所述第一傳輸協議是基於數據報的網絡協議或面向可靠連接的傳輸協議。第一安全協議應用裝置在第一傳輸協議之上應用第一傳輸安全協議。重建器重建接收到的第一數據分組的頭部，使得所述頭部對應於被中間設備經由第二網絡接收到的第二數據分組的頭部，所述第二網絡是基於第二傳輸協議的，在第二傳輸協議之上第二傳輸安全協議正被使用。第一數據分組經由第一網絡從中間設備被接收。驗證器在經重建的第一數據分組的頭部的基礎上來驗證接收到的數據分組的安全驗證欄位。驗證欄位依據第二傳輸安全協議被生成。
[0030]根據本發明的第三方面，另外的第一設備被提供用於在根據本發明的第一方面的通信系統中使用。第一設備包括第一網絡接口、第一安全協議應用裝置、重建器以及生成器。第一網絡接口經由第一網絡與其它設備進行通信。第一網絡是基於第一傳輸協議的，所述第一傳輸協議是基於數據報的網絡協議或面向可靠連接的傳輸協議。第一安全協議應用裝置在第一傳輸協議之上應用第一傳輸安全協議。重建器重建接收到的第一數據分組的頭部，使得所述頭部對應於被中間設備經由第二網絡接收到的第二數據分組的頭部，所述第二網絡是基於第二傳輸協議的，在第二傳輸協議之上第二傳輸安全協議正被使用。第一數據分組經由第一網絡從中間設備被接收。生成器被配置成為要被發送的第三數據分組生成安全驗證欄位。安全驗證欄位在經重建的第一數據分組的頭部的基礎上被生成並且依據第二傳輸安全協議被生成。
[0031]根據本發明的第二方面的第一設備提供了與根據本發明的第一方面的系統相同的益處，並且具有與所述系統的對應實施例具有類似效果的類似實施例。
[0032]根據本發明的第三方面，中間設備被提供用於在根據本發明的第二方面的通信系統中的一個中應用。中間設備包括第一網絡接口、第二網絡接口、第一安全應用裝置、第二安全應用裝置以及修改器。第一網絡接口經由第一網絡與第一設備進行通信。第一網絡是基於第一傳輸協議的。第二網絡接口經由第二網絡與第二設備進行通信。第二網絡是基於第二傳輸協議的。第一網絡協議或第二網絡協議是基於數據報的網絡協議並且第一網絡協議或第二網絡協議中的另一個協議是面向可靠連接的傳輸協議。第一安全應用裝置在第一傳輸協議之上應用第一傳輸安全協議。第二安全應用裝置在第二傳輸協議之上應用第二傳輸安全協議。所述修改器將經由所述第一網絡接收的並且依據第一傳輸安全協議被生成的數據分組修改成用於依據第二傳輸安全協議經由第二網絡傳送的數據分組，並且反之亦然。
[0033]根據本發明的第三方面的中間設備提供了與根據本發明的第一方面的系統相同的益處，並且具有與所述系統的對應實施例具有類似效果的類似實施例。
[0034]根據本發明的第四方面，在第一設備與第二設備之間安全地傳送數據分組的方法被提供。所述方法包括以下步驟:i)經由第一網絡來接收第一數據分組，所述第一網絡為基於第一傳輸協議的，第一傳輸安全協議被應用在第一傳輸協議之上，?)將第一數據分組修改為要經由第二網絡被發送的第二數據分組，所述第二網絡為基於第二傳輸協議的，第二傳輸安全協議被應用在第二傳輸協議之上，第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議，iii)經由第二網絡來發送第二數據分組，iv)接收第二數據分組，V)重建從中間設備接收到的第二數據分組的頭部使得所述頭部對應於第一分組的頭部，vi)在經重建的第一數據分組的頭部的基礎上來驗證接收到的數據分組的安全驗證欄位，所述驗證欄位依據第一傳輸安全協議被生成。應指出，包括驗證欄位的所接收到的數據分組可以是所接收到的第二數據分組或者是比第二數據分組更晚接收到的另一數據分組。
[0035]根據本發明的第四方面，在第一設備與第二設備之間安全地傳送數據分組的另外的方法被提供。所述方法包括以下步驟:i)經由第一網絡來接收第一數據分組，所述第一網絡為基於第一傳輸協議的，第一傳輸安全協議被應用在第一傳輸協議之上，ii)將第一數據分組修改為要被經由第二網絡發送的第二數據分組，所述第二網絡為基於第二傳輸協議的，第二傳輸安全協議被應用在第二傳輸協議之上，第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議，iii)經由第二網絡來發送第二數據分組，iv)接收第二數據分組，V)重建從中間設備接收到的第二數據分組的`頭部，使得所述頭部對應於第一分組的頭部，vi)為第三數據分組生成安全驗證欄位，所述安全驗證欄位在經重建的第一數據分組的頭部的基礎上被生成並且依據第一傳輸安全協議被生成，以及vii)經由第二網絡發送第三數據分組。
[0036]根據本發明的第四方面的方法提供了與根據本發明的第一方面的系統相同的益處，並且具有與所述系統的對應實施例具有類似效果的類似實施例。
[0037]本發明的這些和其它方面從在下文中所描述的實施例中是明顯的，並且將參考在下文中所描述的實施例而被闡述。
[0038]本領域的技術人員將理解，本發明的上面提到的選項、實施方案和/或方面中的兩個或更多個可以被以認為有用的任何方式組合。
[0039]系統、方法的修改和變化和/或與所描述的系統的修改和變化對應的電腦程式產品的修改和變化能夠由本領域的技術人員基於本說明書而被執行。
【專利附圖】

【附圖說明】
[0040]在附圖中: 圖1示意性地示出了根據本發明的第一方面的系統，
圖2a和圖2b示意性地示出了跨越網際網路到6L0WPAN網絡的安全的端到端通信架構，每個都包括本發明的實施例，
圖3a示意性地示出了採用PSK的TLS握手協議的時序圖，
圖3b示意性地示出了採用PSK的DTLD握手協議的時序圖，
圖4a示意性地示出了 OSI模型中的TLS和DTLS，
圖4b示意性地示出了具有突出的DTLS特定欄位的TLS/DTLS分組的結構，
圖4c示意性地示出了具有突出的DTLS特定欄位的TLS/DTLS握手消息的結構，
圖5a意性地示出了具有突出的DTLS特定欄位的TLS / DTLS ClientHello消息的結
構，
圖5b示意性地示出了 DTLS HelloVerifyRequest消息的結構，
圖6示意性地示出了組合的TLS / DTLS握手協議，
圖7示意性地示出了針對CoAP伺服器的流程圖，所述CoAP伺服器用於接收並且驗證完成消息以及然後生成適當的完成消息並將其發送到客戶端，
圖8a示意性地示出了本發明的第一方法的流程圖，以及 圖Sb示意性地示出了本發明的第二方法的流程圖。
[0041 ] 應指出，在不同的圖中由相同的附圖標記所表示的項目具有相同的結構特徵和相同的功能，或者是相同的信號。在這樣的項目的功能和/或結構已被說明的情況下，在【具體實施方式】中沒有對其進行重複說明的必要。
[0042]圖純粹地是圖解的並且未按比例繪製。特別地，為了清楚，一些尺寸被強烈地誇大了。
【具體實施方式】
[0043]根據本發明的第一方面的系統100的第一實施例在圖1中被不意性地不出。系統100包括使用第一傳輸協議的第一網絡120。第一傳輸安全協議可以被使用在第一傳輸協議之上。系統100進一步包括使用第二傳輸協議的第二網絡108。第二傳輸安全協議可以被使用在第二傳輸協議之上。第一設備124或另外的第一設備136被耦合到第一網絡120。中間設備110被耦合在第一網絡120與第二網絡108中間。第二設備102被耦合到第二網絡 108。
[0044]第二設備102具有第二網絡接口 106，所述第二網絡接口 106被直接地耦合到第二網絡108並且其應用第二傳輸協議。第二網絡接口 106被耦合到第二安全協議應用裝置104，所述第二安全協議應用裝置104對從第二設備102傳送到第二網絡108的數據和被第二設備102從第二網絡108接收的數據應用第二傳輸安全協議。
[0045]中間設備110同樣包括第二網絡接口 106，所述第二網絡接口 106提供中間設備110與第二網絡108之間的連接。第二安全協議應用裝置104被中間設備110用來操控第二傳輸安全協議以用於經由第二網絡通信。中間設備110被進一步耦合到具有第一網絡接口 126的第一網絡120，並且中間設備進一步包括第一安全協議應用裝置128以用於在第一網絡120的第一傳輸協議之上應用第一傳輸安全協議。中間設備110的重要功能之一被修改器122執行，所述修改器122將經由第一網絡接收的並且依據第一傳輸安全協議被生成的數據分組修改成用於依據第二傳輸安全協議經由第二網絡傳送的數據分組，並且反之亦然。修改器122執行第一傳輸協議到第二傳輸協議以及反之亦然的轉化，並且執行第一傳輸安全協議到第二傳輸安全協議以及反之亦然的轉化。作為修改的結果，數據分組的頭部被改變，並且常常取決於所使用的特定協議，有效載荷常常未被觸及。
[0046]在實施例中，修改器122未積極地牽涉到第一傳輸安全協議和/或第二傳輸安全協議中。這意味著修改器122沒有秘密密鑰的知識，所述秘密密鑰被用在相應的傳輸安全協議中並且不建立端到端的連接。修改器122僅改變數據分組的頭部使得它們能夠被單獨的網絡正確地傳輸。進一步地，對直接地涉及傳輸協議和傳輸安全協議的組合的分組頭部的相對簡單的修改可以被同樣被修改器122執行。例如，數據報傳輸層安全(DTLS)協議將有限數目的欄位添加到數據分組的分組頭部，所述欄位最初由傳輸層安全協議生成。附加的欄位提供功能性使得傳輸層安全(TLS)能夠作為傳輸協議被用在用戶數據報協議(UDP)之上。在例子中，修改器122添加這種欄位而不用具有關於相應的傳輸安全協議的安全信息的知識。
[0047]在圖1中，第一設備124、136的兩個不同的實施例被呈現。
[0048]第一設備124的第一實施例包括將第一設備124連接到第一網絡120的第一網絡接口 126。第一設備124還具有第一傳輸安全協議應用裝置128，其能夠對經由第一網絡120的通信應用第一傳輸安全協議。第一設備124還包括重建器130，所述重建器130將經由第一網絡120接收到的數據分組的頭部重建成這樣的數據分組的頭部，好像它是被經由第二網絡108發送的並且好像第二傳輸安全協議被應用於通信。因此，換句話說，重建器130能夠顛倒中間設備110的修改器122的操作。第一設備124進一步包括驗證器132，所述驗證器132能夠在經重建的(一個或多個)頭部的基礎上來驗證在接收到的數據分組中的驗證欄位。在數據分組中接收到的驗證欄位可以源自於在第二傳輸安全協議的基礎上生成數據分組的第二設備102，並且因此，所述驗證欄位還是在第二傳輸安全協議的基礎上被生成的驗證欄位。大多數傳輸安全協議在依據特定傳輸安全協議發送的數據分組的一個或多個頭部的基礎上來生成驗證欄位。因此，為了能夠驗證這種驗證欄位，一個或多個頭部首先必須被重建，這由重建器130來完成。取決於特定驗證欄位，驗證器132是否能夠驗證該驗證欄位來建立端到端連接，或者接收到的數據分組的真實性能夠被確認。
[0049]第一設備136的第二實施例與第一設備124的第一實施例類似，僅第二實施例的第一設備136不具有驗證器132但具有用於為要被發送的數據分組生成安全驗證欄位的生成器134。安全驗證欄位在經重建的第一數據分組的頭部的基礎上被生成並且依據第二傳輸安全協議被生成。因此，第一設備136能夠將數據分組發送到能夠驗證這種驗證欄位的第二設備102。因此，如果第二設備102能夠肯定地驗證這種驗證欄位，則安全的端到端連接能夠被建立，或者傳送的數據分組的真實性可以被第二設備確認。
[0050]應指出，第一設備124的第一實施例和第一設備136的第二實施例還可以被組合在包括驗證器132和生成器134的單個設備中。
[0051]圖2a說明了便於實現跨越網際網路到受限IP網絡(例如6L0WPAN網絡)的通信的架構。目標是使得被連接到網際網路的舊系統(傳輸層安全(TLS)客戶端)能夠與受限應用協議(CoAP)伺服器建立安全的端到端(D)TLS握手，然而代理/邊界路由器不學習該握手的秘密。[0052]當在TLS客戶端與CoAP伺服器之間執行(D) TLS握手時，代理/邊界路由器(中間設備)負責轉化TLS分組以及然後將它們重新包裝到對應的DTLS分組中，並且反之亦然。
[0053]在握手結束時，CoAP伺服器能夠區分通信客戶端是正在運行TLS或DTLS，並且它然後能夠生成對應的「完成消息(Finished Message)」以便完成握手。這確保現有舊客戶端能夠與CoAP伺服器建立安全的E2E握手，而無需對客戶端邏輯的任何修改。
[0054]握手還利用了 DTLS與TCP之間的跨層優化，因為有效的TLS客戶端的存在能夠由代理/邊界路由器使用TCP Sync Random(同步隨機)來確定，同時使DTLS cookie機制保持對於6L0WPAN網絡而言為本地的。
[0055]因為CoAP伺服器不知道它是正在與HTTP客戶端或CoAP客戶端交互，並且重要的是使舊系統(即，HTTP客戶端)保持不變，所以額外的邏輯在CoAP設備中的「TLS ext」中是需要的，以便確保(D)TLS握手協議能夠與TLS客戶端一起成功地完成。
[0056]在握手期間TLS與DTLS之間的差異
在兩個對等體能夠藉助於(D)TLS和預共享密鑰以安全的方式交換消息之前，它們必須協商數個安全參數，例如CipherSuite (密碼套件)、壓縮方法或密鑰標識。這由(D)TLS握手來完成，還包含通信實體的認證。圖3a和圖3b分別說明了採用預共享密鑰(PSK)的TLS和DTLS握手的時序圖。標記有*的消息是可選的。
[0057]當使用TLS時，HTTP客戶端首先與用於創建會話密鑰的它的可用的CipherSuite和現時標誌(nonce) —起發送ClientHello消息。CoAP伺服器挑選所提供的CipherSuite中的一個並且在ServerHello消息中將它回送到客戶端。現在應由伺服器在ServerKeyExchange中提供「PSK identity hint (PSK標識暗示)」,這幫助客戶端選擇適當的密鑰。在沒有暗示能夠被提供情況下，這個消息被省略。為了指示hello-消息階段的結束，伺服器發送ServerHel1Done消息。現在HTTP客戶端在有或沒有來自伺服器的暗示的情況下通過發送ClientKeyExchange消息來指示哪一個密鑰被使用。在發送ChangeCipherSpec消息之後,握手將被用完成(Finished)消息來認證。TLS完成消息使用偽隨機函數(PRF)來計算，所述偽隨機函數取主秘密、完成標籤(「客戶端完成」)以及除完成消息本身之外到這時交換的所有握手類型的消息的級聯的哈希作為輸入。在成功的認證和密鑰協定時，信息能夠通過安全連接而被傳送。
[0058]像在TLS中那樣，在DTLS中客戶端從ClientHello消息開始。如上面所提到的那樣,cookie機制能夠被用於驗證客戶端的存在。最初,這個欄位被設置為空。現在，應由伺服器決定cookie將被使用還是不使用。如果不使用，則它發送5θ--θ--θ11ο消息,否則包括cookie的HelloVerifyRequest消息被發送到客戶端。在後者情況下，客戶端再次發送具有相同參數的汝770消息，但包括從伺服器給出的cookie。在那之後，消息以像在TLS中的相同的順序和相同的方式被交換。
[0059]TLS和DTLS分糹目的結構
如圖4a中所說明的那樣，(D)TLS在應用層與傳輸層之間被分層。它同樣示出了(D)TLS是分層的協議。記錄協議(Record Protocol)位於較低層上,然而四個協議被定義在上層上，即握手協議(Handshake Protocol)、警報協議(Alert Protocol)、改變密碼規格協議(ChangeCipherSpec Protocol)以及應用數據協議(Application Data Protocol)。這些協議中的每一個都提供它自己的消息，其必須被以定義的時間點和方式發送。[0060]針對記錄消息的通用設計在圖4b中被示出。因為在握手的完成之前沒有安全參數被建立，所以這些消息未被加密或者不包括MAC，其在圖4c中被示出。TLS與DTLS之間的差異被突出。對於記錄消息來說，那意指DTLS將兩個以上的欄位添加在頭部，尤其是出現時間(epoch)和序列號。
[0061]對於握手消息頭部，消息序列號和分段偏移加上分段長度被添加了。
[0062]圖5a中所說明的ClientHello消息添加了針對cookie的欄位，並且HelloVerifyRequest 不存在於 TLS 中(圖 5b)。
[0063]在圖6中，經組合的TLS-DTLS握手被描繪。代理負責藉助於添加或去除僅與DTLS相關的欄位將TLS分組轉化為DTLS分組並且反之亦然。在伺服器想要使用cookie並且發送HelloVerifyRequest消息的情況下，代理不可將消息轉發到HTTP客戶端，因為這個消息類型在TLS中未被使用。替代地，代理用具有從伺服器給出的cookie的第二 ClientHello消息來回答CoAP伺服器。如果完成消息到達，則代理必須將該消息轉發到伺服器。因為它不擁有在客戶端與伺服器之間共享的秘密，所以它不能夠改變和驗證這個消息中的數據。代理的另一任務指的是DTLS重傳漏掉的消息的能力。因為這是DTLS客戶端的責任，所以代理同樣必須提供可靠的傳輸。
[0064]針對不同的協議來交換和計算完成消肩、的內容
如在前一節中所提到的那樣，當完成握手協議時，完成消息被發送以便對握手進行認證。完成消息基本上包含僅一個欄位，即按如下被計算的驗證數據(Verify Data):
PRF (主_秘密，完成標籤,Msh (握手_消息))[0..驗證_數據_長度-1]
其中完成標籤對於客戶端來說是「客戶端完成」，以及對於伺服器來說是「伺服器完成」。參數握手_消息是所有先前交換的消息的級聯(concatenation)。
[0065]第一完成消息被HTTP客戶端發送到HTTP/CoAP代理。如在前一節中所描述的那樣，代理負責通過將出現時間(Epoch)和序列號添加在記錄頭部中而將TLS格式的完成消息轉化為DTLS格式。然而，代理不能夠再計算驗證_數據，因為它不具有主_秘密，其是在客戶端與伺服器之間共享的、在握手階段期間協商的秘密。完成消息然後通過代理而被發送到CoAP伺服器。
[0066]CoAP伺服器通過使用相同的PRF函數來驗證客戶端完成消息(Client FinishedMessage)。因為客戶端完成消息是DTLS握手消息類型(從消息中的記錄頭部和握手頭部獲知的)，所以CoAP伺服器基於所有先前的DTLS握手消息(不包括完成消息它本身)來計算驗證_數據欄位，並且對照客戶端完成消息來驗證它。如果驗證是成功的，則CoAP伺服器將伺服器完成消息(Server Finished Message)的DTLS版本發送到代理。否則，如果驗證不是成功的，則CoAP伺服器將不觸發(致命)錯誤警報(Error Alert)或者終止交換，但替代地將假定客戶端是HTTP客戶端(TLS)，並且從而它必須再次再計算驗證_數據欄位。然而，這時，它去除所有先前的握手消息中的附加的DTLS欄位(S卩，用TLS握手頭部替換DTLS握手頭部並且去除ClientHello消息中的cookie欄位)。如果這驗證了客戶端完成消息，則它確認客戶端是HTTP客戶端(TLS)。隨後，它準備對應的伺服器完成消息使得它能夠被HTTP客戶端(TLS)驗證，從而完成握手協議以便在HTTP客戶端與CoAP伺服器之間建立安全的端到端隧道。
[0067]因此，通過首先試圖將客戶端發送的「完成」消息作為DTLS消息來驗證，並且然後當這個驗證失敗時，試圖將「完成」消息作為TLS消息來驗證，CoAP伺服器能夠區分CoAP/DTLS客戶端和HTTP/TLS客戶端，並且能夠針對兩種情況生成適當的伺服器「完成」消息。這還在圖7中被示出。如果「完成」消息被接收到702，則「完成」消息在DTLS協議的基礎上被驗證704。如果驗證的結果是肯定的，因此在消息被驗證了的條件下,「ChangeCipherSpec」消息依據DTLS協議被發送706並且握手通過發送708 DTLS「完成」消息來完成。如果驗證704不是肯定的，則DTLS內容被從接收消息的頭部去除710，並且必要時，同樣被從先前的消息的頭部去除。隨後，「完成」消息在TLS協議的基礎上被驗證712。如果驗證712是肯定的，因此，「完成」消息的驗證欄位能夠在經修改的頭部的基礎上被驗證，「ChangeCipherSpec」消息被發送714，後面是發送716 TLS 「完成」消息。如果驗證712不是肯定的，則錯誤被警報718並且連接被關閉720。
[0068]TLS伺服器與CoAP客戶端之間的安全的端到端通信
在不同的場景中以及在圖2b中被示出，在一些應用中，約束設備充當通過網際網路經由HTTP/CoAP代理與後端中的伺服器交互的客戶端是可能的。在這個設置中，客戶端典型地針對事件、信息以及數據例如使用GET函數輪詢伺服器。在這個場景中，目標是使得CoAP客戶端能夠執行與舊伺服器的端到端的安全握手，而代理/邊界路由器不學習該握手的秘密。在這個上下文中，(D)TLS握手仍然由CoAP客戶端通過經由代理/邊界路由器將ClientHello消息發送到TLS伺服器而被發起，所述代理/邊界路由器負責將DTLS分組轉化為TLS分組並且反之亦然。除了兩個端點設備的角色已被顛倒外，(D)TLS握手協議保持與先前所描述的相同。代理的角色保持不變:它分別在向/從DTLS客戶端轉發消息時添加/去除DTLS特定的欄位。
[0069]然而，因為CoAP客戶端不知道它是正在與HTTP伺服器或CoAP伺服器交互，並且重要的是使舊系統(即，HTTP伺服器)保持不變，所以額外的邏輯在CoAP設備中的「TLSext」中是需要的，以便確保(D)TLS握手協議能夠與TLS伺服器一起成功地完成。
[0070]特別地，CoAP客戶端必須根據(D)TLS握手協議經由代理將第一完成消息發送到TLS伺服器，然而如果完成消息包含根據DTLS協議計算的驗證_數據，則它不能夠被TLS伺服器驗證。下文概述了可能的解決方案:
1.CoAP客戶端生成兩個「完成」消息，第一消息是TLS 「完成」消息並且第二消息是DTLS 「完成」消息，以及將這兩個消息發送到代理。代理然後決定要被轉發到TSL伺服器的適當的「完成」消息。
2.CoAP客戶端首先生成DTLS 「完成」消息並且經由代理將它發送到TLS伺服器。清楚地，TLS伺服器將不能夠驗證DTLS 「完成」消息並且將解密_錯誤消息發送到CoAP客戶端(經由代理)。當這個消息指示致命錯誤時，握手將被終止。CoAP客戶端然後學習到它正在與之進行通信的實體是舊TLS伺服器，並且重新發起DTLS/TLS握手協議，從而確保它現在為TLS伺服器生成正確的TLS 「完成」消息。附加地，DTLS客戶能夠存儲關於伺服器DTLS/TLS能力的信息，並且隨後將正確的「完成」消息用作為第一消息，這然後縮短交換。
3.CoAP客戶端首先生成TLS 「完成」消息並且經由代理將它發送到TLS伺服器。如果「完成」消息的驗證是成功的，則安全的端到端隧道被建立在TLS伺服器與CoAP客戶端之間。否則，如果端點是CoAP Server (DTLS)而不是HTTP伺服器(TLS)，則「完成」消息的驗證將失敗。然而，儘管「完成」消息的驗證已經失敗了，但是將不存在在DTLS中報告的致命錯誤。從而，CoAP客戶端隨後能夠為CoAP伺服器(DTLS)生成正確的DTLS 「完成」消息以便完成握手。這具有CoAP客戶端不需要重新發起DTLS/TLS握手的優點。
[0071]圖8a示出了根據本發明的第四方面的方法800。方法800是用於在第一設備與第二設備之間安全地傳送數據分組的。方法800包括以下步驟:i)經由第一網絡來接收802第一數據分組，所述第一網絡是基於第一傳輸協議的，第一傳輸安全協議被應用在第一傳輸協議之上；ii)將第一數據分組修改804為要被經由第二網絡發送的第二數據分組，所述第二數據分組是基於第二傳輸協議的，第二傳輸安全協議被應用在第二傳輸協議之上，第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議；iii)經由第二網絡來發送806第二數據分組；iv)接收808第二數據分組；v)重建810從中間設備接收到的第二數據分組的頭部使得所述頭部對應於第一分組的頭部；vi)在經重建的第一數據分組的頭部的基礎上來驗證812第二數據分組的或第三數據分組的安全驗證欄位，所述驗證欄位依據第一傳輸安全協議被生成。
[0072]圖Sb示出了根據本發明的第四方面的另外的方法850。方法850是用於在第一設備與第二設備之間安全地傳送數據分組的。方法850包括以下步驟:i)經由第一網絡來接收852第一數據分組，所述第一網絡是基於第一傳輸協議的，第一傳輸安全協議被應用在第一傳輸協議之上；ii)將第一數據分組修改854為要被經由第二網絡發送的第二數據分組，所述第二網絡是基於第二傳輸協議的，第二傳輸安全協議被應用在第二傳輸協議之上，第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議；iii)經由第二網絡來發送856第二數據分組；iv)接收858第二數據分組；V)重建860從中間設備接收到的第二數據分組的頭部使得所述頭部對應於第一分組的頭部；vi)為第三數據分組生成862安全驗證欄位，所述安全驗證欄位在經重建的第一數據分組的頭部的基礎上被生成並且依據第一傳輸安全協議被生成；vii)經由第二網絡來發送864第三數據分組。
[0073]簡言之，本發明能夠被概括為:本發明提供用於建立端到端的安全連接和用於安全地傳送數據分組的方法、設備以及通信系統。這樣的通信系統包括第一設備、中間設備以及第二設備。第一設備經由第一網絡與中間設備進行通信，所述第一網絡是基於第一傳輸協議和第一傳輸安全協議的。第二設備經由第二網絡與中間設備進行通信，所述第二網絡是基於第二傳輸協議和第二傳輸安全協議的。中間設備將經由第一網絡接收到的分組修改為適合於第二網絡的分組，並且反之亦然。第一設備能夠重建接收到的分組的頭部好像該分組是經由第二網絡及其傳輸和安全協議被發送的。進一步地，第一設備能夠在經重建的頭部的基礎上來驗證在第二傳輸安全協議的基礎上被生成的驗證欄位。
[0074]應指出，上面提到的實施例說明而不是限制本發明，並且本領域的技術人員將能夠在不背離所附權利要求的範圍的情況下設計許多替代實施例。
[0075]在權利要求中，放置在括弧之間的任何附圖標記不應該被解釋為限制權利要求。動詞「包括」及其詞形變化的使用不排除在權利要求中所陳述的那些以外的元素或步驟的存在。在元素之前的冠詞「一」或「一個」不排除多個這種元素的存在。本發明可以藉助於包括數個不同元件的硬體並且藉助於適當地編程的計算機來實施。在枚舉了數個裝置的設備權利要求中，這些裝置中的數個可以由同一個硬體的項目來體現。某些措施被記載在相互不同的從屬權利要求中的僅有事實不指示這些措施的組合不可以被用來獲利。
【權利要求】
1.一種用於在第一設備與第二設備之間安全地傳送數據分組的通信系統(100)，所述通信系統(100)包括 -第一網絡(120),其是基於第一傳輸協議的， -第一設備(124，136)，其被配置成經由第一網絡(120)與其它設備進行通信，所述第一設備(124，136)被配置成在第一傳輸協議之上應用第一傳輸安全協議， -第二網絡(108)，其是基於第二傳輸協議的， -第二設備(102)，其被配置成經由第二網絡(108)與其它設備進行通信，所述第二設備(102)被配置成在第二傳輸協議之上應用第二傳輸安全協議， -中間設備(110)，其被配置成經由第一網絡(120)與第一設備(124，136)進行通信並且被配置成經由第二網絡(108)與第二設備(102)進行通信，以及被配置成將依據第一傳輸安全協議被生成的經由第一網絡(120)接收到的數據分組修改成用於依據第二傳輸安全協議經由第二網絡(108)傳送的數據分組，並且反之亦然， 其中 -第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議， -第一設備(124，136)被配置成重建從中間設備(110)接收到的第一數據分組的頭部使得所述頭部對應於第二分組的頭部，所述第二分組被第二設備(102)傳送到中間設備(110)並且被中間設備(110)修改為第一數據分組， -第一設備(124)被配置成在經重建的所述第一數據分組的頭部的基礎上來驗證接收到的數據分組的安全驗證欄位，所述驗證欄位由第二設備依據第二傳輸安全協議來生成。
2.根據權利要求1所述的通信系統(100),其中第一傳輸安全協議和第二傳輸安全協議用握手協議發起安全通信會話，並且所述接收到的數據分組是所述握手協議的數據分組。
3.根據權利要求1所述的通信系統(100)，其中所述接收到的數據分組包括消息認證碼(MAC)作為用於對所述接收到的數據分組的真實性進行認證的安全驗證欄位。
4.根據權利要求1所述的通信系統(100)，其中第一設備(124，136)被配置成首先依據第一傳輸安全協議來驗證所述安全驗證碼，並且如果這個驗證是不成功的，則所述第一數據分組的頭部被重建並且所述安全驗證欄位依據第二傳輸安全協議在所述重建的第一數據分組的頭部的基礎上被驗證。
5.一種用於在第一設備(124，136)與第二設備(102)之間安全地傳送數據分組的通信系統(100)，所述通信系統(100)包括 -第一網絡(120),其是基於第一傳輸協議的， -第一設備(124，136)，其被配置成經由第一網絡(120)與其它設備進行通信，所述第一設備(124，136)被配置成在第一傳輸協議之上應用第一傳輸安全協議， -第二網絡(108)，其是基於第二傳輸協議的， -第二設備(102)，其被配置成經由第二網絡(108)與其它設備進行通信，所述第二設備(102)被配置成在第二傳輸協議之上應用第二傳輸安全協議， -中間設備(110)，其被配置成經由第一網絡(120)與第一設備(124，136)進行通信並且被配置成經由第二網絡(108)與第二設備(102)進行通信，以及被配置成將依據第一傳輸安全協議被生成的經由第一網絡(120)接收到的數據分組修改成用於依據第二傳輸安全協議經由第二網絡(108)傳送的數據分組，並且反之亦然， 其中 -第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議， -第一設備(124，136)被配置成重建從中間設備(110)接收到的第一數據分組的頭部使得所述頭部對應於第二分組的頭部，所述第二分組被第二設備(102)傳送到中間設備(110)並且被中間設備(110)修改為第一數據分組， -第一設備(136)被配置成為要被發送的第三數據分組生成安全驗證欄位，所述安全驗證欄位在經重建的所述第一數據分組的頭部的基礎上被生成並且依據第二傳輸安全協議被生成。
6.根據權利要求5所述的通信系統(100),其中第一傳輸安全協議和第二傳輸安全協議用握手協議發起安全通信會話，並且要被發送的第三數據分組是所述握手協議的數據分組。
7.根據權利要求5所述的通信系統(100)，其中第一設備(124，136)被配置成發送包括依據第一傳輸安全協議生成的安全驗證欄位的第四數據分組並且被配置成發送包括依據第二傳輸安全協議生成的安全欄位的第三數據分組。
8.根據權利要求5所 述的通信系統(100)，其中第一設備(124，136)被配置成檢測第一設備(124，136)是否與應用第二傳輸安全協議的另一設備進行通信，並且其中第一設備(124，136)被配置成:如果第一設備(124，136)檢測到它與應用第二傳輸安全協議的另一設備進行通信，則發送包括依據第二傳輸安全協議生成的安全欄位的第三數據分組。
9.根據權利要求1或權利要求5所述的通信系統(100)，其中第一網絡傳輸通信協議是基於網際協議的用戶數據報協議，第二網絡傳輸通信協議是基於網際協議的傳輸控制協議，第一傳輸安全協議是數據報傳輸層安全協議，並且第二傳輸安全協議是傳輸層安全協議。
10.根據權利要求1或權利要求5所述的通信系統(100)，其中第一設備(124，136)被配置成應用受限應用協議並且第二設備被配置成應用超文本傳送協議。
11.一種用於在根據權利要求1所述的通信系統(100)中被使用的第一設備(124)，所述第一設備(124)包括 -第一網絡接口(126)，其被配置成經由第一網絡(120)與其它設備進行通信，第一網絡(120)是基於第一傳輸協議的，第一網絡協議是基於數據報的網絡協議或面向可靠連接的傳輸協議， -第一安全協議應用裝置(128)，其被配置成在第一傳輸協議之上應用第一傳輸安全協議， 其中 -重建器(130)，其被配置成重建被接收的第一數據分組的頭部使得所述頭部對應於第二分組的頭部，所述第二分組被中間設備(110)經由第二網絡(108)接收，第二網絡是基於第二傳輸協議的，在第二傳輸協議之上第二傳輸安全協議正被使用，第一數據分組經由第一網絡(120)被從中間設備(110)接收， -驗證器(132)，其被配置成在經重建的第一數據分組的頭部的基礎上來驗證接收到的數據分組的安全驗證欄位，所述驗證欄位依據第二傳輸安全協議被生成。
12.一種用於在根據權利要求5所述的通信系統(100)中被使用的第一設備(136)，所述第一設備(136)包括 -第一網絡接口(126)，其被配置成經由第一網絡(120)與其它設備進行通信，第一網絡(120)是基於第一傳輸協議的，第一網絡協議是基於數據報的網絡協議或面向可靠連接的傳輸協議， -第一安全協議應用裝置(128)，其被配置成在第一傳輸協議之上應用第一傳輸安全協議， 其中 -重建器(130)，其被配置成重建接收到的第一數據分組的頭部使得所述頭部對應於第二數據分組的頭部，所述第二數據分組被中間設備(110)經由第二網絡(108)接收，第二網絡是基於第二傳輸協議的，在第二傳輸協議之上第二傳輸安全協議正被使用，第一數據分組經由第一網絡(120)被從中間設備(110)接收， -生成器(134)，其被配置成為要被發送的第三數據分組生成安全驗證欄位，所述安全驗證欄位在經重建 的第一數據分組的頭部的基礎上被生成並且依據第二傳輸安全協議被生成。
13.一種用於在根據權利要求1或5中任何一項所述的通信系統(100)中被應用的中間設備(110)，所述中間設備(110)包括 -第一網絡接口(126)，其被配置成經由第一網絡(120)與第一設備(124，136)進行通信，第一網絡(120)是基於第一傳輸協議的， -第二網絡接口(106)，其被配置成經由第二網絡(108)與第二設備(102)進行通信，第二網絡(108)是基於第二傳輸協議的， -第一安全應用裝置(128)，其被配置成在第一傳輸協議之上應用第一傳輸安全協議，-第二安全應用裝置(104)，其被配置成在第二傳輸協議之上應用第二傳輸安全協議，第一網絡協議或第二網絡協議是基於數據報的網絡協議並且第一網絡協議或第二網絡協議中的另一個協議是面向可靠連接的傳輸協議，以及 -修改器(122)，其被配置成將經由第一網絡(120)接收到的並且依據第一傳輸安全協議被生成的數據分組修改成用於依據第二傳輸安全協議經由第二網絡(108)傳送的數據分組，並且反之亦然。
14.一種在第一設備與第二設備之間安全地傳送數據分組的方法(800)，所述方法(800)包括以下步驟: -經由第一網絡來接收(802)第一數據分組，第一網絡是基於第一傳輸協議的，第一傳輸安全協議被應用在第一傳輸協議之上， -將第一數據分組修改(804)為要被經由第二網絡發送的第二數據分組，第二網絡是基於第二傳輸協議的，第二傳輸安全協議被應用在第二傳輸協議之上，第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議，-經由第二網絡來發送(806)所述第二數據分組， -接收(808)所述第二數據分組， -重建(810)從中間設備接收到的所述第二數據分組的頭部使得所述頭部對應於第一分組的頭部， -在經重建的第一數據分組的頭部的基礎上來驗證(812)接收到的數據分組的安全驗證欄位，所述驗證欄位依據第一傳輸安全協議被生成。
15.一種在第一設備與第二設備之間安全地傳送數據分組的方法(850)，所述方法(850)包括以下步驟: -經由第一網絡來接收(852)第一數據分組，第一網絡是基於第一傳輸協議的，第一傳輸安全協議被應用在第一傳輸協議之上， -將第一數據分組修改(854)為要被經由第二網絡發送的第二數據分組，第二網絡是基於第二傳輸協議的，第二傳輸安全協議被應用在第二傳輸協議之上，第一傳輸協議或第二傳輸協議是基於數據報的網絡協議並且第一傳輸協議或第二傳輸協議中的另一個協議是面向可靠連接的傳輸協議， -經由第二網絡來發送(856)所述第二數據分組， -接收(858)所述第二數據分組， -重建(860)從中間設備接收到的所述第二數據分組的頭部使得所述頭部對應於第一分組的頭部， -為第三數據分組生成(862)安全驗證欄位，所述安全驗證欄位在經重建的所述第一數據分組的頭部的基礎上被生成並且依據第一傳輸安全協議被生成， -經由所述第二網絡來發送(864)所述第三數據分組。
【文檔編號】H04L29/00GK103765842SQ201280036786
【公開日】2014年4月30日 申請日期:2012年7月24日 優先權日:2011年7月25日
【發明者】S.L.科奧, O.加西亞莫喬恩, S.S.庫馬, M.布拉奇曼恩, B.埃德曼 申請人:皇家飛利浦有限公司