第三章 系統設計
3.3 安全性設計
務供應商能存取的訊息範圍，若使用者允許授權，應用程式會拿到 access token，接著 應 用 程式 利用 access token 與 一 開 始向 Authorization Server 註 冊 的 身分 資訊 向 Authorization Server 進行驗證(OAuth 驗證流程詳見 2.4.2)，驗證通過後，Authorization Server 則向 ACS 索取使用者的資訊(如：家庭中智慧空調服務的狀態)，ACS 則會向 CPE 來取得這些資訊，再將其回傳給應用程式。若使用者不希望某項資訊暴露給服務 供應商知道，則可選擇拒絕授權，應用程式將不會被下載及安裝。從服務供應商的角 度來看，會希望使用者下載自家開發的服務次數越多越好，因此，所提出的存取授權 要求也應會在合理範圍內。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
36
此外，本研究的架構也考慮資訊安全的資料與資源的機密性、完整性、不可否認 性和身分鑑別與存取權限控制等四個重要的特性，詳細說明如下：
機密性(Confidentiality)
在資訊安全中，機密性表示只有訊息的目標接收者能夠閱讀訊息內容，由於 CWMP 是基於 Web Service 開發技術來實作，採用 W3C SOAP 通訊協定，因此可以透 過 WS-Security(Web Service Security)，來確保 ACS 與 CPE 間傳送資料的機密性，只 有擁有密鑰的 Client 端能夠解密並讀取訊息。WS-Security 是一種提供在 Web 服務上 應用安全的方法的網絡傳輸協議，描述如何將簽章及加密標頭(Header)加至 SOAP 訊 息中，它能保證兩個端點間資料傳輸的安全。透過實作標準的 WS-Security，可將帶安 全性的字串或內容加入至 ACS 與 CPE 間傳送的 SOAP 訊息標頭中，而 Web Service 能取出這些安全內容，並且進行訊息解密以及訊息完整性等工作，架構如圖 3.11。
圖 3.10 使用者隱私資訊授權流程
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
37
WS-Security 實際的運作方法是 Client 端與 Server 端各自生成一對金鑰，透過不對 稱加密的方式來進行訊息加密傳送，假設 Client 端想要向 Server 端傳送私密訊息，則 將訊息透過 Server 端的公鑰(public key)進行加密，並將它嵌入至<xnec:EncrypteKey>
令牌的請求訊息中，即能夠傳送加密訊息給 Server 端，Server 端收到訊息後透過自己 的私鑰解密讀取訊息，以保證訊息的機密性。此方法相對於對稱加密方法較好，由於 使用對稱加密，雙方必須擁有同一把密碼來進行訊息加解密，一旦密碼被竊取，訊息 即公開，安全性較低。
以下將簡單說明 ACS 與 CPE 確保傳送資料保有機密性的運作方式，如圖 3.12：
1. ACS 與 CPE 分別產生自己的一對金鑰，並向憑證機構(Certificate Authority) 註冊，憑證機構將保有金鑰。
2. CPE 欲傳送私密資訊給 ACS，需先向憑證機構拿取 ACS 之公鑰。
3. CPE 將訊息用 ACS 公鑰加密。
4. CPE 傳送加密過後的訊息給 CPE。
5. ACS 透過自己的私鑰將訊息解密，讀取訊息。
圖 3.11 WS-Security 架構示意圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
38
完整性與不可否認性 (Integrity and Non-repudiation)
安全機制中定義的完整性表示訊息傳送的過程中必須證明內容未遭到竄改或偽造；
不可否認性表示使用者不可否認其所做過的事，包括送出、接收訊息，存取資料等，
而透過數位簽章的方式可以達到完整性及不可否認性。WS-Security 機制中，Client 與 Server 端生成的保密密鑰(private key)可用來進行解密以及簽章，若有人欲更改訊息內 容，都需要進行數位簽章，否則簽名無效，即表示訊息被竄改。以下將簡單說明 ACS 與 CPE 確保傳送資料保有完整性及不可否認性的運作方式，如圖 3.13：
1. ACS 與 CPE 分別產生自己的保密密鑰，並向憑證機構註冊。
2. 當註冊者身分被驗證後，憑證機構會發佈結合註冊者的公開金鑰的數位憑證，
且憑證機構會將資料存在資料庫中。
3. 假設 CPE 欲傳送私密資訊給 ACS，他只需以自己的私鑰對文件作簽章，ACS 圖 3.12 ACS 與 CPE 確保資料機密性的運作流程圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
39
這端只需透過憑證機構的資料庫取得 CPE 的公鑰即可驗證文件是否來自 CPE。
i. 由於 CPE 先將欲傳送之明文利用雜湊函數產生一份文件，並用 CPE 的私鑰將其加密，將其變成一個文摘(digest)，再連同文件一併傳送 給 ACS。
ii. 因此，ACS 收到文件後，首先用與 CPE 相同的雜湊函數與收到的 明文算出這個雜湊計算，而得到的雜湊值即為文摘(digest)。
iii. 再利用 CPE 的公鑰解開 CPE 送來的文摘內容。
iv. 比對兩者是否相同即可確認文件是否由 CPE 所簽署。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
40
圖 3.13 ACS 與 CPE 確保資料完整性與不可否認性的運作流程圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
41
身分鑑別與存取權限控制(Authentication and Authorization)
本論文設計的管理架構中，利用 OAuth2.0 及數位簽章技術實作身分認證及授權功 能。在 ACS 與 CPE 連線之前，雙方需先互相進行身分認證，CPE 需透過 google 會員 帳號作登入，若登入成功，即通過 ACS 之使用者認證；ACS 則是透過數位簽章之方 式向 CPE 做認證，CPE 會亂數產生一個字串，將加密後的字串傳送給 ACS，ACS 廠 商會擁有一把 private key，因此，若 ACS 收到亂數字串後，能夠解密，回傳正確的字 串給 CPE，即通過 CPE 驗證，視為可信任之服務廠商，待雙方皆相互認證通過後即可 建立連線會話。另外，本研究也考慮存取權限控制的功能，使用者從商務網站所購買 並下載的智慧服務應用程式，必須透過使用者的授權，才能在家中設備上進行安裝，
並且僅能對使用者所授權存取的使用者資料進行存取，而上述的兩個安全設計將能達 到身分鑑別與存取權限控制功能。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
42