MRCP协议学习笔记-六大安全问题讨论

到此章节为止，我们已经基本上完成了所有关于MRCP协议的细节讨论。但是，我们没有讨论关于MRCP的安全问题。MRCP协议在客户端和服务器端的交互过程中涉及了SIP协议的处理，基于互联网的分布式处理数据流程，媒体会话的控制和语音文件存储传输，返回数据的传输等内容，如果没有对每个环节进行安全处理的话，语音识别或者其他的智能客服系统都会出现安全问题。在今天的分享中，我们将讨论关于MRCP协议中必须遵守的安全规范以及相关框架。

1

MRCP协议在设计之初就考虑了关于安全的问题，安全机制的设置必须遵守SPEECHSC 架构的要求。具体SPEECHSC要求是通过RFC 4313来规定的。RFC 4313对在分布式环境中的语音识别，说话人验证确认，TTS都做了相应的规范要求。SPEECHSC的实现架构关于语音处理的流程如下图所示：

在不同的业务处理中，其流程有一定的区别。以下是关于TTS的架构：

以下是关于ASR的架构实现：

在说话人验证中，RFC 4313支持了以下架构：

以上这些处理流程，事实上都和我们以前所介绍的MRCP协议中的处理流程是完全相同的，这里，笔者罗列这些架构是为了说明MRCP协议 RFC6878是根据RFC 4313对ASR，说话人验证和TTS的细节应用。今天，我们的重点不是介绍RFC 4313，我们的重点是讨论MRCP协议的安全问题。如果读者对其有兴趣的话，可以进一步阅读RFC 4313-Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources。

在MRCP协议中，我们将重点讨论几个方面的内容，这些内容涉及了创建会话，控制会话通道，数据传输和数据存储，DTMF缓冲溢出等相关话题。另外，读者一定要注意，在规范中，有一些的规定是必须遵守的，有一些规定是比较宽泛，没有强制要求的。如果读者需要了解更多详情，请参阅RFC4313。

2

首先，我们讨论会话创建的安全问题。在MRCP v2的部署使用中，MRCP控制会话的创建是通过媒体会话来实现。媒体会话则包含在了SIP dialog 的SDP中。因此，为了确保MRCP客户端和服务器端之间的安全，必须遵守几个要求：

MRCP客户端和服务器的部署的SIP必须支持digest authentication（rfc321），并且应该使用这种方式。

在MRCP客户端和服务器的部署的SIP必须支持“sips” URL, 应该使用这种方式。这个包括了是否通过TLS（rfc5246）创建的连接中。

如果媒体流的cryptographic密钥是通过SDP完成，MRCP客户端和服务器端必须使用sips URL。

当在SIP中使用了TLS，MRCP客户端必须验证服务器端的身份信息，验证规则遵守RFC5922。

3

刚才，我们讨论了会话创建时的安全问题。现在我们讨论关于控制通道的安全保护问题。大家知道，比较敏感的数据都是通过MRCP的控制通道来传输。被传输的数据中可能是语音识别的输出结果，说话人验证结果，通话中TTS的输入数据，个人语法等结果。这些数据必须是通过认证机制，以便确保MRCP客户端和服务器端安全的数据传输。为了确保控制通道的安全保护，除非还有其他第三方的控制通道的保护措施，MRCP客户端和服务器端必须支持TLS作为默认设置。当双方启用了TLS连接时，MRCP客户端必须验证服务器端的身份，验证流程需要遵守RFC4572。注意，这里和前面的验证流程不同。在控制会话创建时需要遵守的验证流程是RFC5922。

如果在MRCP客户端和服务器端存在多个TLS保护的通道的话，服务器端不能通过通道对客户端发送响应消息。这一部分的定义在RFC中解释的比较费解，笔者也没有完全理解其真正含义。笔者可参阅更多资料来消化此部分内容。

因为，有一些通过媒体会话传输的比较敏感的数据通过MRCP服务器端来结束，因此，媒体会话的保护也是非常重要的。这些数据可能包括说话人语句，TTS输出结果。MRCP v2 必须支持语音媒体数据的保护机制。发起或使用语音数据的MRCP 客户端必须支持语音数据的保护机制，例如，使用SRTP（RFC3711）。

4

MRCPv2也需要对间接访问数据内容进行保护。很多使用场景中，MRCP 客户端都需要通过URL获取或存储这些数据内容。因此，MRCP客户端和服务器端都必须支持HTTPS或FTPS来访问一些间接内容数据。如果MRCP客户端可以通过URL访问服务器端，那么，服务器端则会面临很多安全风险，例如，DOS攻击。很多攻击者可能使用URL对MRCP服务器端进行DOS攻击。

另外，MRCP 服务器对没有对URL资源设定访问时间或认证内容的设置。如果有URL访问泄漏，那么也会导致内容泄漏。MRCP服务器端没有对内容访问时间做规定，URL数据的访问时间长短取决于内容数据的大小。因此，如果会话结束后，MRCP服务器端就会立即删除资源的URL。

5

存储文件的安全问题也是MRCP服务器的安全问题之一。MRCP应用程序经常需要访问已存储的文件，例如语音文件，录音等。声纹文件会使用在语音验证中，因此MRCP 服务器端应该提供这些文件所需要的安全保护机制。

声纹删除和签权管理也是一个需要注意到安全问题。在MRCP v2中，如果需要删除声纹的话（发起一个DELETE-VOICEPRINT请求时），没有专门针对验证和签权的机制和细节规定。因此，这样就会带来一个潜在的安全风险，MRCP 服务器端可能不会对终端进行验证和签权进行检查。在一般生产环境中，语音识别的解决方案提供商会对这些数据进行验证签权的处理，因此，目前看不是一个主要的问题。未来，如果解决方案提供商需要进一步的验证的话，在未来MRCP版本中会增加此类支持。

6

缓冲溢出是系统安全中经常可能发生的问题。在MRCP的部署环境中，DTMF缓冲和语音识别缓冲会随着应用程序处理能力的增加也不断增加，有时可能会超出MRCP服务器所支持的能力。因此，MRCP服务器必须能够支持缓冲处理能力。如果服务器端资源不足或缺少资源支持的情况下，服务器端可以返回不完整的识别结果。

7

客户端设置参数导致的安全问题。在某些场景中，客户端可以对服务器端进行一些参数设置控制文件获取超时设置等相关消息。Fetch-Timeout 就是一个担心的例子。在这些客户端设置参数的处理流程中，可能有一些黑客使用MRCP客户端设置一个非常大的超时设置来获取一个可能根本不存在的文件。这样的话，MRCP服务器端会在长时间内完全和这个会话绑定，最后可能导致服务器端瘫痪。因此，MRCP服务器端必须非常谨慎对MRCP客户端的这些敏感参数设置进行检测，服务器端拒绝或建议一个相对比较适中的值，以防止安全问题发生。

8

在本章节关于MRCP安全的讨论中，我们重点讨论了关于MRCP安全架构的基本要求，然后介绍了创建会话时需要使用的安全机制，控制会话中所要求的规定和一张流程，我们还讨论了内容访问时的签权机制，DTMF缓冲溢出的建议等关于MRCP安全方面的所有潜在安全问题。这些问题是客户在部署MRCP包括声纹验证，语音识别中特别需要关注的问题，希望，通过此分享，读者能够真正意识到这些安全问题，同时按照MRCP v2的规定做出相应的保护设置。

参考资料：

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