放心用吧！淺談DuerOS的安全性

“我們每個人都是安全工作者”（參見關于軟體開發，都應該知道的10個常識），這絕不是一句戲言。在人工智能智能領域，安全同樣是一個重要的話題。AI作業系統要保證系統的安全性，那麼基于AI作業系統的開放平台同樣要保證安全性。

基于DuerOS 的小度系列音箱是否安全？基于DuerOS開發的技能服務是否安全呢？

小度系列音箱的安全性

很多朋友問我，“使用小度音箱是否安全呢？它是不是總在監聽我說話呢？”。

《智能音箱場景下的性能優化》一文中描述了智能音箱的工作原理，音箱的喚醒和語音識别是兩個部分。當使用者說“小度小度”喚醒詞的時候，這部分的語音識别是在音箱本地進行的，也就是音箱自身的AI部分，當喚醒完成之後，使用者的語音才會傳到DuerOS的雲端，完成語音識别，自然語言處理等等。舉個例子，大家在一個屋子裡聊天，很多聲音你可以充耳不聞，當我說“小明，小明”，小明才會意識到我要和他說話，對我接下來的對話進行響應。

是以，智能音箱并沒有将使用者的語音都進行雲存儲，隻有在使用者要求音箱響應的時候才做出來，是相對安全的。

至于智能音箱其他方面的安全性都是要遵守各種國家規範的，就小度系列音箱而言，有着嚴格的準入準出機制，包括顯式/隐式接口，存儲晶片，加密等級，固件更新等，基本上可以做到比手機的安全性更好。

DuerOS的安全體系

DuerOS系統的安全性建構在百度整個的安全體系之上，安全體系一般包括六個方面：

實體與環境安全
安全流程管理及相關審計
災難恢複和業務連續性
雲平台安全技術
雲客戶雲安全服務
資料安全

安全架構的核心包括百度智能網關、入侵檢測和防禦系統，流量清洗系統和漏洞檢測系統等，可有效實作防DDoS以及各類網絡4、7層攻擊等。

百度釋出了公司層面的《資料安全政策》，所有資料進行分級保護。所有使用者敏感資訊，将以最高安全等級“機密”級别進行管理。在處理機密資料資産時，必須遵守機密資料管理流程與技術标準要求。主要包括：

所有的資料有明确的資料owner和管理者，明确資料通路/使用範圍，遵循資料通路權限最小化原則。并通過技術手段和相關流程對資料進行安全管理，推動保護措施的實施。
釋出明确的制度對機密資料的通路、擷取進行管理，包括第三方需求的管理。建立明确的通路授權審批要求且所有審批記錄線上化。
各系統或使用者知道明确的資料銷毀處理流程，并采用合理的資料銷毀技術。
對機密資料管理執行定期稽核。
所有承載、存儲機密資料的系統，必須具備4A基本要求（Account、Authentication、Authorization、Audit）。機密資料的通路必須細化到個人，必須有安全的登入機制，所有人的通路已授權且符合最小化原則，所有行為日志記錄齊全且遠端備份滿足可審計。

是以， DuerOS系統自身的安全性是值得信賴的。

DBP技能開放平台的安全性

DBP（DuerOS Bot Platform）是對開發者開放的平台，以通信認證的方式保證DuerOS 系統與第三方服務的安全性。也就是說，在技能服務與DuerOS通信的過程中，雙方都需要對接收到的請求資訊進行認證，避免接收到惡意攻擊者發來的請求，進而保證通信内容安全。

在傳輸層面，技能服務必須使用HTTPS進行通信，以保證通信内容的傳輸安全。應用服務層面的安全性采用的是雙向認證。

雙向認證——DBP請求第三方服務

當DuerOS向技能發送請求時，技能需要對發來的請求進行驗證，驗證過程如下：

從http head的signaturecerturl位址裡面下載下傳權威簽名證書，然後從簽名證書中擷取公鑰。
從http head中擷取signature資訊，并用base64解碼signature得到str1。
通過公鑰和str1解密得到sign1。如果解密成功，繼續驗證。如果解密失敗則拒絕請求。
使用sha1計算消息body的内容得到sign2，并與sign1進行比較，如果一緻則繼續驗證，如果不一緻，則拒絕請求。
比較request請求消息中的timestamp字段與系統目前的時間，如果兩者內插補點小于180秒，則認為目前請求合法，對請求進行處理。如果兩者內插補點大于等于180秒，則拒絕請求。

驗證過程中的2-4步可以使用rsa_verify函數代替。下圖展示了DuerOS生成簽名過程和技能驗證簽名的過程。

雙向認證——第三方服務請求DBP服務

當DuerOS收到技能發送的請求時，需要對技能發來的請求進行驗證，驗證步驟如下。

從http head中擷取signature，并進行base64位解密獲得str1。
從DBP平台上擷取技能的公鑰，并将公鑰與str1通過解密獲得sign1，如果解密失敗則拒絕請求。
将body、botId、timestamp三個字元串按順序連接配接成str2，并對str2生成摘要sign2，比較sign1與sign2是否相同，如果不同則決絕請求，如果相同，則繼續驗證。
比較請求消息中的timestamp字段與系統目前時間，如果兩者內插補點小于180秒，則認為請求合法，對請求進行處理。如果兩者內插補點大于等于180秒，則拒絕請求。

DuerOS驗證簽名過程中的2-3步可以使用rsa_verify函數代替。下圖展示了技能生成簽名過程和DuerOS驗證簽名的過程。

生成公私鑰的RSA方法

RSA方法生成的公鑰和私鑰是成對出現的，在DuerOS與技能通信過程中起着重要的作用。可以采用OpenSSL來生成RSA的公私鑰，私鑰的生成示例如下：

genrsa -out rsa_private_key.pem 1024

根據私鑰生成公鑰的方式如下：

rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem

沒錯，和我們在其他環境中的應用沒什麼兩樣。

當然，如果采用了CFC的形式進行部署，DBP 平台已經完成了上述功能，無需開發者顯示操作。

使用者隐私與賬戶管理

安全性中的一個重要方面是使用者隐私，在DuerOS中所有涉及使用者隐私的操作都要使用者的顯式授權，例如位置資訊，錄音，支付等等。例如技能向使用者推薦附近的美食時需要知道使用者的位址資訊，向使用者郵箱推送使用者關注的資訊時需要使用者的郵箱資訊。技能隻有經過使用者的授權才能使用使用者的資訊。

使用者授權

技能可以通過向DuerOS發送Permission.AskForPermissionsConsent指令擷取使用者的權限。當收到使用者響應時，DuerOS會向技能發送授權成功或授權失敗事件。

Permission.AskForPermissionsConsent指令的協定格式如下：

{
    "type": "Permission.AskForPermissionsConsent",
    "permissions": [
        {
            "name": "{{ENUM}}"
        },
        ...
    ],
    "token": "{{STRING}}"
}

複制

當技能申請使用者授權成功時，DuerOS會向技能上報授權成功事件，消息格式如下：

{
    "type": "{{STRING}}",
    "requestId": "{{STRING}}",
    "timestamp": "{{STRING}}",
    "token": "{{STRING}}" 
}

複制

如果技能需要使用者授權的資料，必須在DBP 平台的技能描述進行顯式選擇。為了保護使用者資料，技能在使用使用者資料資訊必須滿足以下條件。如果發現技能違背了下面的原則，DuerOS有權下線技能，并通知開發者對技能進行修改。

技能必須滿足DuerOS隐私政策。
技能隻有在提供服務時才能使用使用者資訊。使用使用者資訊時，必須告知使用者使用範圍，在使用者同意并且不違背使用者隐私和法律的情況下使用。
技能使用使用者資訊，包括使用者的昵稱、郵箱、電話、頭像等，都必須通過向DuerOS發送請求消息來擷取，不能将使用者的資訊本地存儲。
技能每次提供服務時，必須使用API接口請求使用者最新的資訊。

賬戶關聯

另一類典型的授權需求是賬戶關聯，需要将使用者的DuerOS賬号與已有應用系統的賬戶進行關聯，以擷取應用系統的資訊。DuerOS支援技能将使用者的DuerOS賬戶與使用者的其他系統賬号關聯起來，使技能提供更多的服務。

目前，在DBP技能開放平台上，僅自定義技能和智能家居技能會涉及賬戶關聯功能，内容播報等技能不涉及賬戶關聯。例如，當使用者使用一個關于微網誌内容分享的自定義技能時，如果使用者說“小度小度，檢視我的關注”，此時技能會為使用者展現微網誌的關注資訊。在這個過程中，技能首先需要擷取使用者在微網誌賬戶的授權，然後才能登入使用者的微網誌，擷取微網誌的關注資訊并展現。

技能将使用者的DuerOS賬戶與使用者的第三方系統帳戶關聯時，需要第三方系統為該使用者賬戶提供一個通路令牌，以便在第三方系統中唯一地辨別使用者。DuerOS儲存通路令牌，并将令牌包含在發送給技能的請求中。技能使用通路令牌代表使用者身份通路第三方系統，通過該系統的身份驗證，進而擷取到使用者在該系統中的資訊或者資源。

DuerOS 采用OAuth 2.0的授權碼模式完成賬戶關聯，過程如下：

當需要使用者授權時，會在螢幕或app（無屏裝置啟用技能時）上顯示第三方系統的登入頁面(即開放平台的填寫的授權位址)。技能請求該授權位址時會攜帶 state（必選）、client_id（必選）、response_type（必選）、scope（可選）和redirect_uri（必選） 等參數資訊。
使用者在第三方系統的登入界面填寫賬戶資訊并進行登入授權。
第三方系統對使用者的身份進行驗證。通過身份驗證後第三方系統會重定向到redirect_uri位址，并附上授權碼。
重定向位址redirect_uri使用授權碼向認證伺服器（在技能開放平台上填寫的token位址）申請令牌。
認證伺服器核對授權碼和redirect_uri，确認無誤後，向DuerOS發送access token和refresh token。
DuerOS驗證傳回資訊，儲存access token和refresh token。

也就是說，當技能應用支援使用者使用帳戶關聯功能時，開發者需要設計、編寫登入頁面。該頁面需要驗證使用者在第三方系統的登入資訊，并傳回通路令牌。如使用者在技能商店app中啟用智能家居技能時，會跳轉到技能提供的第三方系統的登入界面。使用者登入第三方系統進行通路授權，該頁面驗證使用者的資訊是否正确，正确時傳回通路令牌。登入頁面需要滿足以下要求：

基于HTTPS通路。
可以适配不同的裝置，包括手機app、各種有屏裝置端。
不允許出現任何彈出視窗。
必須接受使用者的登入資訊憑據，然後對使用者進行身份驗證。
需要能生成一個授權碼code，該code可以傳遞到技能的授權伺服器并傳回access token通路令牌。
必須跟蹤查詢字元串中傳遞的state值，及原封不動的傳回該state的值。
完成使用者登入資訊驗證時，需要重定向到redirect_uri位址，同時攜帶參數state和授權碼code。

當使用者禁用技能時，DuerOS将删除技能與該使用者關聯的通路令牌和重新整理令牌，取消該使用者的DuerOS賬戶與使用者其他系統賬戶之間的連接配接。當使用者再次啟用技能時，需要重新将使用者的DuerOS賬戶與提供服務的使用者賬戶進行關聯。

綜上所述，在使用基于DuerOS的各種服務時，無論從裝置端，還是AI作業系統，亦或第三方技能服務，都在安全性上提供一定的保證，一句話，放心用吧！