1、MRCP協(xié)議在設計之初就考慮了關于安全的問題，安全機制的設置必須遵守SPEECHSC 架構的要求。具體SPEECHSC要求是通過RFC 4313來規(guī)定的。RFC 4313對在分布式環(huán)境中的語音識別，說話人驗證確認，TTS都做了相應的規(guī)范要求。SPEECHSC的實現(xiàn)架構關于語音處理的流程如下圖所示：

　　在不同的業(yè)務處理中，其流程有一定的區(qū)別。以下是關于TTS的架構：

　　以下是關于ASR的架構實現(xiàn)：

　　在說話人驗證中，RFC 4313支持了以下架構：

　　以上這些處理流程，事實上都和我們以前所介紹的MRCP協(xié)議中的處理流程是完全相同的，這里，筆者羅列這些架構是為了說明MRCP協(xié)議 RFC6878是根據RFC 4313對ASR，說話人驗證和TTS的細節(jié)應用。今天，我們的重點不是介紹RFC 4313，我們的重點是討論MRCP協(xié)議的安全問題。如果讀者對其有興趣的話，可以進一步閱讀RFC 4313-Requirements for Distributed Control of Automatic Speech Recognition （ASR）, Speaker Identification/Speaker Verification （SI/SV）, and Text-to-Speech （TTS） Resources。

　　在MRCP協(xié)議中，我們將重點討論幾個方面的內容，這些內容涉及了創(chuàng)建會話，控制會話通道，數據傳輸和數據存儲，DTMF緩沖溢出等相關話題。另外，讀者一定要注意，在規(guī)范中，有一些的規(guī)定是必須遵守的，有一些規(guī)定是比較寬泛，沒有強制要求的。如果讀者需要了解更多詳情，請參閱RFC4313。

　　2、首先，我們討論會話創(chuàng)建的安全問題。在MRCP v2的部署使用中，MRCP控制會話的創(chuàng)建是通過媒體會話來實現(xiàn)。媒體會話則包含在了SIP dialog 的SDP中。因此，為了確保MRCP客戶端和服務器端之間的安全，必須遵守幾個要求：

　　3、剛才，我們討論了會話創(chuàng)建時的安全問題�，F(xiàn)在我們討論關于控制通道的安全保護問題。大家知道，比較敏感的數據都是通過MRCP的控制通道來傳輸。被傳輸的數據中可能是語音識別的輸出結果，說話人驗證結果，通話中TTS的輸入數據，個人語法等結果。這些數據必須是通過認證機制，以便確保MRCP客戶端和服務器端安全的數據傳輸。為了確�？刂仆ǖ赖陌踩�保護，除非還有其他第三方的控制通道的保護措施，MRCP客戶端和服務器端必須支持TLS作為默認設置。當雙方啟用了TLS連接時，MRCP客戶端必須驗證服務器端的身份，驗證流程需要遵守RFC4572。注意，這里和前面的驗證流程不同。在控制會話創(chuàng)建時需要遵守的驗證流程是RFC5922。

　　如果在MRCP客戶端和服務器端存在多個TLS保護的通道的話，服務器端不能通過通道對客戶端發(fā)送響應消息。這一部分的定義在RFC中解釋的比較費解，筆者也沒有完全理解其真正含義。筆者可參閱更多資料來消化此部分內容。

　　因為，有一些通過媒體會話傳輸的比較敏感的數據通過MRCP服務器端來結束，因此，媒體會話的保護也是非常重要的。這些數據可能包括說話人語句，TTS輸出結果。MRCP v2 必須支持語音媒體數據的保護機制。發(fā)起或使用語音數據的MRCP 客戶端必須支持語音數據的保護機制，例如，使用SRTP（RFC3711）。

　　4、MRCPv2也需要對間接訪問數據內容進行保護。很多使用場景中，MRCP 客戶端都需要通過URL獲取或存儲這些數據內容。因此，MRCP客戶端和服務器端都必須支持HTTPS或FTPS來訪問一些間接內容數據。如果MRCP客戶端可以通過URL訪問服務器端，那么，服務器端則會面臨很多安全風險，例如，DOS攻擊。很多攻擊者可能使用URL對MRCP服務器端進行DOS攻擊。

　　另外，MRCP 服務器對沒有對URL資源設定訪問時間或認證內容的設置。如果有URL訪問泄漏，那么也會導致內容泄漏。MRCP服務器端沒有對內容訪問時間做規(guī)定，URL數據的訪問時間長短取決于內容數據的大小。因此，如果會話結束后，MRCP服務器端就會立即刪除資源的URL。

　　5、存儲文件的安全問題也是MRCP服務器的安全問題之一。MRCP應用程序經常需要訪問已存儲的文件，例如語音文件，錄音等。聲紋文件會使用在語音驗證中，因此MRCP 服務器端應該提供這些文件所需要的安全保護機制。

　　聲紋刪除和簽權管理也是一個需要注意到安全問題。在MRCP v2中，如果需要刪除聲紋的話（發(fā)起一個DELETE-VOICEPRINT請求時），沒有專門針對驗證和簽權的機制和細節(jié)規(guī)定。因此，這樣就會帶來一個潛在的安全風險，MRCP 服務器端可能不會對終端進行驗證和簽權進行檢查。在一般生產環(huán)境中，語音識別的解決方案提供商會對這些數據進行驗證簽權的處理，因此，目前看不是一個主要的問題。未來，如果解決方案提供商需要進一步的驗證的話，在未來MRCP版本中會增加此類支持。

　　6、緩沖溢出是系統(tǒng)安全中經常可能發(fā)生的問題。在MRCP的部署環(huán)境中，DTMF緩沖和語音識別緩沖會隨著應用程序處理能力的增加也不斷增加，有時可能會超出MRCP服務器所支持的能力。因此，MRCP服務器必須能夠支持緩沖處理能力。如果服務器端資源不足或缺少資源支持的情況下，服務器端可以返回不完整的識別結果。

　　7、客戶端設置參數導致的安全問題。在某些場景中，客戶端可以對服務器端進行一些參數設置控制文件獲取超時設置等相關消息。Fetch-Timeout 就是一個擔心的例子。在這些客戶端設置參數的處理流程中，可能有一些黑客使用MRCP客戶端設置一個非常大的超時設置來獲取一個可能根本不存在的文件。這樣的話，MRCP服務器端會在長時間內完全和這個會話綁定，最后可能導致服務器端癱瘓。因此，MRCP服務器端必須非常謹慎對MRCP客戶端的這些敏感參數設置進行檢測，服務器端拒絕或建議一個相對比較適中的值，以防止安全問題發(fā)生。

　　8、在本章節(jié)關于MRCP安全的討論中，我們重點討論了關于MRCP安全架構的基本要求，然后介紹了創(chuàng)建會話時需要使用的安全機制，控制會話中所要求的規(guī)定和一張流程，我們還討論了內容訪問時的簽權機制，DTMF緩沖溢出的建議等關于MRCP安全方面的所有潛在安全問題。這些問題是客戶在部署MRCP包括聲紋驗證，語音識別中特別需要關注的問題，希望，通過此分享，讀者能夠真正意識到這些安全問題，同時按照MRCP v2的規(guī)定做出相應的保護設置。

　　參考資料：

　　https://tools.ietf.org/pdf/rfc4313.pdf