欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當(dāng)前的位置是:  首頁(yè) > 新聞 > 國(guó)內(nèi) >
 首頁(yè) > 新聞 > 國(guó)內(nèi) >

MRCP協(xié)議學(xué)習(xí)筆記-六大安全問題討論

2018-08-13 15:48:54   作者: james.zhu   來源:CTI論壇   評(píng)論:0  點(diǎn)擊:


  到此章節(jié)為止,我們已經(jīng)基本上完成了所有關(guān)于MRCP協(xié)議的細(xì)節(jié)討論。但是,我們沒有討論關(guān)于MRCP的安全問題。MRCP協(xié)議在客戶端和服務(wù)器端的交互過程中涉及了SIP協(xié)議的處理,基于互聯(lián)網(wǎng)的分布式處理數(shù)據(jù)流程,媒體會(huì)話的控制和語(yǔ)音文件存儲(chǔ)傳輸,返回?cái)?shù)據(jù)的傳輸?shù)葍?nèi)容,如果沒有對(duì)每個(gè)環(huán)節(jié)進(jìn)行安全處理的話,語(yǔ)音識(shí)別或者其他的智能客服系統(tǒng)都會(huì)出現(xiàn)安全問題。在今天的分享中,我們將討論關(guān)于MRCP協(xié)議中必須遵守的安全規(guī)范以及相關(guān)框架。
  1、MRCP協(xié)議在設(shè)計(jì)之初就考慮了關(guān)于安全的問題,安全機(jī)制的設(shè)置必須遵守SPEECHSC 架構(gòu)的要求。具體SPEECHSC要求是通過RFC 4313來規(guī)定的。RFC 4313對(duì)在分布式環(huán)境中的語(yǔ)音識(shí)別,說話人驗(yàn)證確認(rèn),TTS都做了相應(yīng)的規(guī)范要求。SPEECHSC的實(shí)現(xiàn)架構(gòu)關(guān)于語(yǔ)音處理的流程如下圖所示:
  在不同的業(yè)務(wù)處理中,其流程有一定的區(qū)別。以下是關(guān)于TTS的架構(gòu):
  以下是關(guān)于ASR的架構(gòu)實(shí)現(xiàn):
  在說話人驗(yàn)證中,RFC 4313支持了以下架構(gòu):
  以上這些處理流程,事實(shí)上都和我們以前所介紹的MRCP協(xié)議中的處理流程是完全相同的,這里,筆者羅列這些架構(gòu)是為了說明MRCP協(xié)議 RFC6878是根據(jù)RFC 4313對(duì)ASR,說話人驗(yàn)證和TTS的細(xì)節(jié)應(yīng)用。今天,我們的重點(diǎn)不是介紹RFC 4313,我們的重點(diǎn)是討論MRCP協(xié)議的安全問題。如果讀者對(duì)其有興趣的話,可以進(jìn)一步閱讀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é)議中,我們將重點(diǎn)討論幾個(gè)方面的內(nèi)容,這些內(nèi)容涉及了創(chuàng)建會(huì)話,控制會(huì)話通道,數(shù)據(jù)傳輸和數(shù)據(jù)存儲(chǔ),DTMF緩沖溢出等相關(guān)話題。另外,讀者一定要注意,在規(guī)范中,有一些的規(guī)定是必須遵守的,有一些規(guī)定是比較寬泛,沒有強(qiáng)制要求的。如果讀者需要了解更多詳情,請(qǐng)參閱RFC4313。
  2、首先,我們討論會(huì)話創(chuàng)建的安全問題。在MRCP v2的部署使用中,MRCP控制會(huì)話的創(chuàng)建是通過媒體會(huì)話來實(shí)現(xiàn)。媒體會(huì)話則包含在了SIP dialog 的SDP中。因此,為了確保MRCP客戶端和服務(wù)器端之間的安全,必須遵守幾個(gè)要求:
  • MRCP客戶端和服務(wù)器的部署的SIP必須支持digest authentication(rfc321),并且應(yīng)該使用這種方式。
  • 在MRCP客戶端和服務(wù)器的部署的SIP必須支持“sips” URL, 應(yīng)該使用這種方式。這個(gè)包括了是否通過TLS(rfc5246)創(chuàng)建的連接中。
  • 如果媒體流的cryptographic密鑰是通過SDP完成,MRCP客戶端和服務(wù)器端必須使用sips URL。
  • 當(dāng)在SIP中使用了TLS,MRCP客戶端必須驗(yàn)證服務(wù)器端的身份信息,驗(yàn)證規(guī)則遵守RFC5922。
  3、剛才,我們討論了會(huì)話創(chuàng)建時(shí)的安全問題,F(xiàn)在我們討論關(guān)于控制通道的安全保護(hù)問題。大家知道,比較敏感的數(shù)據(jù)都是通過MRCP的控制通道來傳輸。被傳輸?shù)臄?shù)據(jù)中可能是語(yǔ)音識(shí)別的輸出結(jié)果,說話人驗(yàn)證結(jié)果,通話中TTS的輸入數(shù)據(jù),個(gè)人語(yǔ)法等結(jié)果。這些數(shù)據(jù)必須是通過認(rèn)證機(jī)制,以便確保MRCP客戶端和服務(wù)器端安全的數(shù)據(jù)傳輸。為了確?刂仆ǖ赖陌踩Wo(hù),除非還有其他第三方的控制通道的保護(hù)措施,MRCP客戶端和服務(wù)器端必須支持TLS作為默認(rèn)設(shè)置。當(dāng)雙方啟用了TLS連接時(shí),MRCP客戶端必須驗(yàn)證服務(wù)器端的身份,驗(yàn)證流程需要遵守RFC4572。注意,這里和前面的驗(yàn)證流程不同。在控制會(huì)話創(chuàng)建時(shí)需要遵守的驗(yàn)證流程是RFC5922。
  如果在MRCP客戶端和服務(wù)器端存在多個(gè)TLS保護(hù)的通道的話,服務(wù)器端不能通過通道對(duì)客戶端發(fā)送響應(yīng)消息。這一部分的定義在RFC中解釋的比較費(fèi)解,筆者也沒有完全理解其真正含義。筆者可參閱更多資料來消化此部分內(nèi)容。
  因?yàn),有一些通過媒體會(huì)話傳輸?shù)谋容^敏感的數(shù)據(jù)通過MRCP服務(wù)器端來結(jié)束,因此,媒體會(huì)話的保護(hù)也是非常重要的。這些數(shù)據(jù)可能包括說話人語(yǔ)句,TTS輸出結(jié)果。MRCP v2 必須支持語(yǔ)音媒體數(shù)據(jù)的保護(hù)機(jī)制。發(fā)起或使用語(yǔ)音數(shù)據(jù)的MRCP 客戶端必須支持語(yǔ)音數(shù)據(jù)的保護(hù)機(jī)制,例如,使用SRTP(RFC3711)。
  4、MRCPv2也需要對(duì)間接訪問數(shù)據(jù)內(nèi)容進(jìn)行保護(hù)。很多使用場(chǎng)景中,MRCP 客戶端都需要通過URL獲取或存儲(chǔ)這些數(shù)據(jù)內(nèi)容。因此,MRCP客戶端和服務(wù)器端都必須支持HTTPS或FTPS來訪問一些間接內(nèi)容數(shù)據(jù)。如果MRCP客戶端可以通過URL訪問服務(wù)器端,那么,服務(wù)器端則會(huì)面臨很多安全風(fēng)險(xiǎn),例如,DOS攻擊。很多攻擊者可能使用URL對(duì)MRCP服務(wù)器端進(jìn)行DOS攻擊。
  另外,MRCP 服務(wù)器對(duì)沒有對(duì)URL資源設(shè)定訪問時(shí)間或認(rèn)證內(nèi)容的設(shè)置。如果有URL訪問泄漏,那么也會(huì)導(dǎo)致內(nèi)容泄漏。MRCP服務(wù)器端沒有對(duì)內(nèi)容訪問時(shí)間做規(guī)定,URL數(shù)據(jù)的訪問時(shí)間長(zhǎng)短取決于內(nèi)容數(shù)據(jù)的大小。因此,如果會(huì)話結(jié)束后,MRCP服務(wù)器端就會(huì)立即刪除資源的URL。
  5、存儲(chǔ)文件的安全問題也是MRCP服務(wù)器的安全問題之一。MRCP應(yīng)用程序經(jīng)常需要訪問已存儲(chǔ)的文件,例如語(yǔ)音文件,錄音等。聲紋文件會(huì)使用在語(yǔ)音驗(yàn)證中,因此MRCP 服務(wù)器端應(yīng)該提供這些文件所需要的安全保護(hù)機(jī)制。
  聲紋刪除和簽權(quán)管理也是一個(gè)需要注意到安全問題。在MRCP v2中,如果需要?jiǎng)h除聲紋的話(發(fā)起一個(gè)DELETE-VOICEPRINT請(qǐng)求時(shí)),沒有專門針對(duì)驗(yàn)證和簽權(quán)的機(jī)制和細(xì)節(jié)規(guī)定。因此,這樣就會(huì)帶來一個(gè)潛在的安全風(fēng)險(xiǎn),MRCP 服務(wù)器端可能不會(huì)對(duì)終端進(jìn)行驗(yàn)證和簽權(quán)進(jìn)行檢查。在一般生產(chǎn)環(huán)境中,語(yǔ)音識(shí)別的解決方案提供商會(huì)對(duì)這些數(shù)據(jù)進(jìn)行驗(yàn)證簽權(quán)的處理,因此,目前看不是一個(gè)主要的問題。未來,如果解決方案提供商需要進(jìn)一步的驗(yàn)證的話,在未來MRCP版本中會(huì)增加此類支持。
  6、緩沖溢出是系統(tǒng)安全中經(jīng)常可能發(fā)生的問題。在MRCP的部署環(huán)境中,DTMF緩沖和語(yǔ)音識(shí)別緩沖會(huì)隨著應(yīng)用程序處理能力的增加也不斷增加,有時(shí)可能會(huì)超出MRCP服務(wù)器所支持的能力。因此,MRCP服務(wù)器必須能夠支持緩沖處理能力。如果服務(wù)器端資源不足或缺少資源支持的情況下,服務(wù)器端可以返回不完整的識(shí)別結(jié)果。
  7、客戶端設(shè)置參數(shù)導(dǎo)致的安全問題。在某些場(chǎng)景中,客戶端可以對(duì)服務(wù)器端進(jìn)行一些參數(shù)設(shè)置控制文件獲取超時(shí)設(shè)置等相關(guān)消息。Fetch-Timeout 就是一個(gè)擔(dān)心的例子。在這些客戶端設(shè)置參數(shù)的處理流程中,可能有一些黑客使用MRCP客戶端設(shè)置一個(gè)非常大的超時(shí)設(shè)置來獲取一個(gè)可能根本不存在的文件。這樣的話,MRCP服務(wù)器端會(huì)在長(zhǎng)時(shí)間內(nèi)完全和這個(gè)會(huì)話綁定,最后可能導(dǎo)致服務(wù)器端癱瘓。因此,MRCP服務(wù)器端必須非常謹(jǐn)慎對(duì)MRCP客戶端的這些敏感參數(shù)設(shè)置進(jìn)行檢測(cè),服務(wù)器端拒絕或建議一個(gè)相對(duì)比較適中的值,以防止安全問題發(fā)生。
  8、在本章節(jié)關(guān)于MRCP安全的討論中,我們重點(diǎn)討論了關(guān)于MRCP安全架構(gòu)的基本要求,然后介紹了創(chuàng)建會(huì)話時(shí)需要使用的安全機(jī)制,控制會(huì)話中所要求的規(guī)定和一張流程,我們還討論了內(nèi)容訪問時(shí)的簽權(quán)機(jī)制,DTMF緩沖溢出的建議等關(guān)于MRCP安全方面的所有潛在安全問題。這些問題是客戶在部署MRCP包括聲紋驗(yàn)證,語(yǔ)音識(shí)別中特別需要關(guān)注的問題,希望,通過此分享,讀者能夠真正意識(shí)到這些安全問題,同時(shí)按照MRCP v2的規(guī)定做出相應(yīng)的保護(hù)設(shè)置。
  參考資料:
  https://tools.ietf.org/pdf/rfc4313.pdf
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn),與CTI論壇無關(guān)。CTI論壇對(duì)文中陳述、觀點(diǎn)判斷保持中立,不對(duì)所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請(qǐng)讀者僅作參考,并請(qǐng)自行承擔(dān)全部責(zé)任。

專題