YD/T 2913-2015
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2913-2015.Security aspects of network enhancement for machine-type communications.
1范围
YD/T 2913规定了移动通信系统承载M2M业务时的触发安全、Tsp接口安全、安全连接以及USIM与MTC设备绑定4个方面的安全技术要求。
YD/T 2913适用于基于3GPP R12承载M2M业务的包括终端、智能卡和系统设备在内的端到端移动通信系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。.
3GPP TS 23.040短消息技术实现(Technical realization of the Short Message Service (SMS))
3GPP TS 23.142短消息增值业务;接口和信令流程(Value-added Services for SMS (VAS4SMS);Interface and signalling flow)
3GPP TS 23.2043GPP IP接入下的短消息业务;阶段2 ( Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2)
3GPP TS 23.682分 组数据网络与应用下设备通讯的架构增强( Architecture Enhancements to facilitate communications with Packet Data Networks and Applications)
3GPP TS 29.368 MTC-IWF 与SCS之间的Tsp接口协议(Tsp interface protocol between the MTC Interworking Function (MTC-IWF) and Service Capability Server (SCS))
1范围
YD/T 2913规定了移动通信系统承载M2M业务时的触发安全、Tsp接口安全、安全连接以及USIM与MTC设备绑定4个方面的安全技术要求。
YD/T 2913适用于基于3GPP R12承载M2M业务的包括终端、智能卡和系统设备在内的端到端移动通信系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。.
3GPP TS 23.040短消息技术实现(Technical realization of the Short Message Service (SMS))
3GPP TS 23.142短消息增值业务;接口和信令流程(Value-added Services for SMS (VAS4SMS);Interface and signalling flow)
3GPP TS 23.2043GPP IP接入下的短消息业务;阶段2 ( Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access; Stage 2)
3GPP TS 23.682分 组数据网络与应用下设备通讯的架构增强( Architecture Enhancements to facilitate communications with Packet Data Networks and Applications)
3GPP TS 29.368 MTC-IWF 与SCS之间的Tsp接口协议(Tsp interface protocol between the MTC Interworking Function (MTC-IWF) and Service Capability Server (SCS))
标准图片预览
标准内容
ICS33.070.99
中华人民共和国通信行业标准
YD/T2913-2015
M2M通信系统增强安全要求
Securityaspectsofnetwork enhancementformachine-typecommunications
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
规范性引用文件·
缩略语：
M2M安全架构和安全需求：
4.1M2M安全架构
安全需求
5Tsp接口安全技术要求
双向鉴权·
安全配置·
MTC终端触发相关安全技术要求.6
过滤设备触发SMS短消息的网络侧方案：6.2
安全连接技术要求
7.2MTC设备发起的安全连接
7.3网络发起的安全连接
8USIM与MTC设备绑定安全技术要求基于UE的USAT应用配对概述
安全技术要求
附录A（资料性附录）M2M应用场景·次
YD/T2913-2015
YD/T2913-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中兴通讯股份有限公司、中国信息通信研究院、华为技术有限公司、大唐电信科技产业集团。
本标准主要起草人：游世林、林兆骥、余万涛、崔媛媛、陈璟、应江威、艾明。
1范围
M2M通信系统增强安全要求
YD/T2913-2015
本标准规定了移动通信系统承载M2M业务时的触发安全、Tsp接口安全、安全连接以及USIM与MTC设备绑定4个方面的安全技术要求。本标准适用于基于3GPPR12承载M2M业务的包括终端、智能卡和系统设备在内的端到端移动通信系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPPTS23.040短消息技术实现（TechnicalrealizationoftheShortMessageService(SMS)）3GPPTS23.142短消息增值业务：接口和信令流程（Value-addedServicesforSMS（VAS4SMS)）；Interface and signalling flow)3GPPTS23.2043GPPIP接入下的短消息业务：阶段2（SupportofShortMessageService(SMS）overgeneric3GPPInternetProtocol (IP)access;Stage2)3GPPTS23.682分组数据网络与应用下设备通讯的架构增强（ArchitectureEnhancementstofacilitate communications with Packet Data Networks and Applications)3GPPTS29.368MTC-IWF与SCS之间的Tsp接协议（TspinterfaceprotocolbetweentheMTCInterworkingFunction (MTC-IWF)and ServiceCapabilityServer (SCS))3GPPTS31.111USIM应用工具箱（Universal SubscriberIdentityModule(USIM)ApplicationToolkit(USAT)\
3GPPTS31.115USIM应用工具箱安全包结构（Securedpacketstructurefor（Universal)SubscriberIdentityModule(U)SIMToolkitapplications)3GPPTS31.116USIM应用工具箱APDU结构，（RemoteAPDUStructurefor(U)SIMToolkitapplications）
3GPPTS33.220通用认证架构(GAA)之通用自举架构，（GenericAuthenticationArchitecture（GAA)；Generic Bootstrapping Architecture (GBA))3GPPTS33.223通用认证架构（GAA）之通用自举架构推送功能（GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture (GBA)Pushfunction)ETSITS102.225智能卡：基于UICC应用的安全包结构（SmartCards；SecuredpacketstructurefoUICCbasedapplications）
ETSITS102.226智能卡：基于UICC应用的远程APDU结构（Smartcards；RemoteAPDUstructureforUICCbasedapplications)
YD/T2913-2015
3缩略语
下列缩略语适用于本文件。
MTC-IWF
Attribute Value Pair
Capabilities-Exchange-AnswerCapabilities-Exchange-RequestEncapsulating Security PayloadGeneral Packet Radio ServiceInternet Key Exchange
Machine-Type Communication
MTC Interworking Function
Public key infrastructure
Service Capability Server
Transport Layer Security
Universal MobileTelecommunications SystemUSIMApplication Toolkit
UMTSSubscriberIdentityModuleUMTS Radio Access Network
User Equipment
UMTS Integrated Circuit Card4M2M安全架构和安全需求
4.1M2M安全架构
备注：T5a，T5b和T5c接口在本标准不做要求。图1定义了一个高层次的机器类通信安全架构。属性值对
能力交换响应
能力交换请求
封装安全有效负载
通用分组无线业务
Internet密钥交换协议下载标准就来标准下载网
机器类通信
机器类通信互联功能
公钥基础设施
业务能力服务器
传输层安全
通用移动通信系统
USIM应用工具
UMTS用户身份模块
UMTS无线接入网
用户设备
UMTS集成电路卡
层次A：MTC设备和3GPP网络之间机器类通信的安全可以进一步分为：AI：MTC设备和无线接入网络之间机器类通信的安全：A2：MTC设备和非接入层之间机器类通信的安全：A3：MTC设备和非3GPP接入之间机器类通信的安全。层次B：3GPP网络和SCS/MTC应用之间机器类通信的安全可以进一步分为：B1：在间接模式下SCS和3GPP网络之间的机器类通信的安全。可以进一步细分为当SCS位于3GPP网络域内与3GPP网络域外的安全。B2：在直接模式下MTC应用和3GPP网络之间的机器类通信的安全。SCS和MTC应用之间的通信在本标准规定范围之外。层次C：MTC设备和SCS/MTC应用之间机器类通信的安全可以进一步分为：C1：在间接模式下MTC服务器和MTC设备之间的机器类通信的安全。C2：在直接模式下MTC应用和MTC设备之间的机器类通信的安全。2
控制面
用户面
归属网络（3GPP网络）
拜访网络（3GPP网络）
M2M设备
4.2安全需求
4.2.1MTC安全需求
移动交
换中心
移动性管
理实体
GPRS克
特节点
短消息
MTC-IWF
分组数据网
服务网关
归属用户
服务器
图13GPPM2M安全架构
MTC认证
服务器
YD/T2913-2015
MTC应用
MTC应用
非直接模式?
直换模式
温合模式
针对MTC的安全需求包括：M2M的优化不能降低优化前通讯系统的安全级别。4.2.2Tsp接口安全需求
Tsp接口应符合如下安全需求：
Tsp接口之间的通讯应提供完整性保护、重放攻击保护、机密性保护和隐私保护：Tsp接口之间的通讯应提供相互认证、鉴权：相互认证的方式见3GPPTS29.368：Tsp接口应使用完整性保护和重放攻击保护；Tsp接口应使用机密性保护；
一Tsp接口应使用隐私保护（比如：IMSI不能传递到非3GPP运营网络之外）。4.2.3MTC-IWF安全需求
MTC-IWF的安全需求与Tsp接口安全需求一致。3
YD/T2913-2015
5Tsp接口安全技术要求
5.1概述
应使用在IETFRFC3588中所定义的Diameter安全机制。5.2双向鉴权
本标准只针对如下部署方式的Tsp接口安全过程：MTC-IWF和SCS之间的Tsp接口上的DIAMETER消息应通过MTC-IWF所在的安全域中的至少一个DIAMETER代理（后文中称为“MTC-IWF侧代理\），和SCS所在的安全域中的一个DIAMETER代理（后文中称为“SCS侧代理\）。也可以有其他的部署方式，但不推荐使用Tsp接口。注1：
MTC-IWF所在的的安全域中的一个节点和SCS所在的安全域中的一个节点之间的双向鉴权应使用IETFRFC3588所定义的TLS或IPsec，除非使用6.3.3中所定义的安全配置。应遵循以下规则：
在MTC-IWF的安全域和SCS的安全域之间不能有存在中间DIAMETER代理的第三个安全域。一在MTC-IWF的安全域中，如果有MTC-IWF侧代理，则由MTC-IWF侧代理作为执行Tsp相关双向鉴权的节点；如果没有MTC-IWF侧代理，则由MTC-IWF作为执行Tsp相关双向鉴权的节点。在SCS的安全域中，如果有SCS侧代理，则由SCS侧代理作为执行Tsp相关双向鉴权的节点：如果没有SCS侧代理，则由SCS作为执行Tsp相关双向鉴权的节点。一各节点应使用TLS或IPsec验证在CER/CEA消息中收到的标识（比如，证书中的名称）的节点标识。一域授权检查：一个收到Tsp相关DIAMETER消息的适当的节点应检查该消息的发出者，即在应用层指定的SCS（或MTC-IWF），是真正被授权通过其标识在之前的步骤中被验证的节点发送该消息的。这项检查可以通过与SCSs（或MTC-IWFs）相关联的本地表格结合其标识可以被接受域验证的初始安全域中的节点执行。执行该域授权检查的节点应是MTC-IWF或发到MTC-IWF的消息的MTC-IWF侧代理，以及SCS或发到SCS的消息的SCS侧代理。注2：
即使存在MTC-IWF侧代理，MTC-IWF也可以执行域安全检查，因为MTC-IWF侧代理在Record-RouteAVP中包含验证过的标识（SCS侧的情况类似）。域授权检查的概念在以上的列举项中定义，而不是来自其他规范性文档。5.3安全配置
在TLS上支持Tsp是强制的。支持IKE/IPsec是可选的。IKE、IPsec和TLS的安全配置应遵循以下规定：一TLS实现和使用的配置应遵循3GPPTS33.310附录E中的规定。双向鉴权应基于根据3GPPTS33.310中6.1.3a节和6.1.4a节的配置的证书。用于这些证书的PKI的结构不在本标准范围内，因此本条中对证书的发出者的规定不适用。
如果支持IKE/IPsec，则实现IKEv2和基于根据3GPPTS33.310配置的证书的双向鉴权是强制的。证书配置应遵循3GPPTS33.310中6.1.3和6.1.4。用于这些证书的PKI的结构不在本标准范围内，因此本条中对证书的发出者的规定不适用。一如果支持IKE/IPsec，则IPsecESP应根据3GPPTS33.210中的配置实现。隧道模式是强制支持的。传输模式是可选支持的。
6MTC终端触发相关安全技术要求6.1概述
YD/T2913-2015
MTC终端触发安全技术方案是基于SMS短消息传递的设备触发消息的过滤的相关技术要求。6.2过滤设备触发SMS短消息的网络侧方案以下方案用于过滤基于SMS短消息传递的设备触发消息。该方案依赖于短消息中的标准化标识，也就是3GPPTS23.040中所定义的TPProtocolID，用于区分触发短消息和其它类型的短消息。该方案进一步假设合法触发短消息的传递需要经过归属域网络中的SMS-SC，以验证通过Tsms接口发送触发短消息的短消息实体身份是否合法；或者经过归属域网络中的MTC-IWF，以验证通过Tsp接口发送触发SM的SCS身份是否合法。归属域网络应该基于3GPPTS23.040，为发给归属域网络用户的短消息终呼实现归属网络路由，以保护这些用户免遭未授权SMS触发消息的攻击（例如，支持SMS触发的终端中的签约）。归属网络路由应该能够将SM传递给HPLMN中的SMS路由器，而不是传递给目标UE的服务MSC/VLR、SGSN、或者MME。如果SMS路由器接收到的SM不是来自于归属域网络中的处理SMS触发消息的SMS-SC，则SMS路由器会将该SM发送给过滤设施，从而过滤并阻止包含触发指示的短消息。参考3GPPTS23.040和3GPPTS23.204所定义的SMS架构和功能，SMSs的传输需要经过SMS-SC。根据M2M机器类通信的架构，对于基于SMS的设备触发，SMS-SC所接收的短消息包含了相关的发送者标识和接收者标识，这些短消息来自三条路径，即通过Tsms接口的短消息实体、T4接口、SMS-IWMSC。过滤SMS触发消息是基于网络侧的，因此伪造的SMS触发消息应该被SMS-SC所识别并阻止。以下描述了SMS-SC如何处理来自于这三条路径的短消息。一如果HPLMN中处理SMS触发消息的SMS-SC所接收的SM不是来自于T4接口，则应该将该SM发送给过滤设施。
一如果过滤设施所接收的SM包含触发指示并且不是源于一个授权发送触发SMs的可信SME，则阻止该SM。
一如果过滤设施所接收的SM包含触发指示并且源于一个授权发送触发SMs的可信SME，则将触发请求SM发送给SME所授权发送的特定UEs。本标准不定义过滤设施如何决定可信SME是否允许将设备触发SM发送给特定的UE。
一如果SMS-SC所接收的SM来自于T4接口的MTC-IWF，则SMS-SC认为T4接口是可信的并继续发送该SM，因为MTC-IWF能认证MTC服务器并且能保证只有授权了的MTC服务器才可以触发特定的MTC设备。
一如果SMS-SC所接收的SM来自于SMS-IWMSC，则SMS-SC应该将SM发送给过滤设施。这样，SMS-SC可以通过检查接收方的授权发送方列表，来决定SM是否来自于一个授权的SME。如果不是，SMS-SC阻止该伪造触发SM的发送。如果MTC-IWF接收的触发请求来自于Tsp接口，则MTC-IWF应该过滤并阻止来自非可信SCS的触发SM，3GPPTS23.682的5.2.1节描述了具体流程。根据3GPPTS23.040的9.2.3.9节，普通UE不允许发送起呼触发短消息来触发MTC设备，因此SMS-SC应该根据普通UE的签约信息来区分并阻止伪造的MO设备触发SMSs根据运营商策略，可信源可以被授权发送触发消息给任何UB。为了防止源欺骗，需要保护用来传5
YD/T2913-2015
输触发消息的接口，特别应该保护Tsms、Tsp、和T4接口。3GPPTS23.682的4.3.3.1节中定义了Tsp接口安全，Tsms接口的安全机制不在本标注研究范围内。可以根据3GPPTS23.142定义的架构来过滤非法SMS。当过滤实体接收到SM后，它能够基于包含在SM中的触发指示（即，3GPPTS23.040定义的TPProtocolID）来识别SM是否为触发SM。上述解决方案中的过滤功能分布于SMS路由器上的过滤设施、SMS-SC上的过滤设施、以及MTC-IWF上的过滤设施。这说明过滤功能需要由能够在本地连接接口上验证SM源的实体所激活。同时SMS路由器只仅仅是MT场景下的一个可选实体，它没有能力验证Tsp和Tsm接口上的消息源，因此只在SMS路由器上实现过滤功能是不足的。实现过滤功能设施的最好位置是SMS-SC，因为它可以过滤来自三条路径的SMs。
解决方案旨在防止未授权实体发送大量的触发消息给大量的MTC设备而造成对核心网的分布式拒绝服务攻击。但是，本方案只是防止了SMS应用层威胁，而没有能够防止网络内部节点或网络信令链接遭受威胁或攻击者滥用所带来的攻击（例如，欺骗的MAP_ForwardShortMessage包含一个触发指示并通过SS7连接发送给目标UEs）。如果需要消除这种攻击或者HPLMN不支持归属网络路由，那么本章的安全解决方案是不足的，因此需要在网络侧的MTC应用和UE的MTC应用之间，实现某种端到端的密码保护机制来保护触发消息。但这种解决方案可能由应用层来提供而不在本标准范围之内。将来的3GPF版本可能还会引入这种密码保护触发消息的解决方案。存在不同网络的短信中心直接连接的场景，因此部署归属网络路由不是强制的。7安全连接技术要求
7.1概述
MTC安全连接特征就是运营商能够为保护MTC设备和SCS之间（非直接模式下）或者MTC设备和MTC应用之间（直接模式下）的应用协议安全提供密钥材料。GBA，如3GPPTS33.220所描述的，用于针对基于3GPPAKA机制的应用安全的自举认证和密钥协商。GBA应被用于为一个MTC设备发起的安全连接建立密钥。作为GBA的扩展，GBAPush在3GPPTS33.223中进行了定义。GBAPush也用于为两个实体间的应用安全建立密钥。
其他机制（例如，在不能应用GBA的场景中使用EAP-AKA）可以用于为MTC设备和MTC服务器之间或者MTC设备和MTC应用服务器之间提供安全连接特征。这些机制被认为不在本标准范围内。在ME和网络之间的安全连接特征实现是可选的。7.2MTC设备发起的安全连接
UE发起的安全连接仅适用于支持HTTP协议的MTC设备。一个MTC设备发起的安全连接应通过3GPPTS33.220定义的GBA方式建立。MTC设备与MTC服务器或者MTC设备与MTC应用服务器之间的安全连接都应使用GBA方式。MTC服务器和MTC应用服务器应作为NAF服务器使用。通过GBA方式建立安全连接密钥的过程具体如下：MTC设备与BSF通过Ub接口执行GBA自举过程。自举过程使得MTC设备和BSF获得一个共享密钥Ks和与该共享密钥Ks关联的一个标识B-TID。MTC设备接着基于Ks生成一个Ks_(ext/int)NAF密钥，并通过Ua接口与目标NAF建立一个连接。在非直接模式下，NAF功能由MTC服务器执行，在直接模式下，NAF6
YD/T2913-2015
功能由MTC应用服务器执行。开始通信时，MTC设备向NAF提供B-TID。NAF向BSF请求B-TID关联的Ks_（ext/int）NAF密钥。这样，MTC设备与MTC服务器/MTC应用服务器就可以使用Ks_（ext/int）NAF密钥保护Ua应用协议（即安全连接）。如何使用Ks_（ext/int）NAF密钥保护MTC设备与MTC服务器之间或MTC设备与MTC应用服务器之间的通信依赖于使用的Ua应用协议。7.3网络发起的安全连接
一个网路发起的安全连接应通过3GPPTS33.223定义的GBAPush方式建立。MTC设备与MTC服务器或者MTC设备与MTC应用服务器之间的安全连接都应使用GBAPush方式。MTC服务器和MTC应用服务器应作为PushNAF服务器使用。通过GBAPush方式建立安全连接密钥的过程具体如下：
PushNAF服务器，即非直接模式下的MTC服务器和直接模式下的MTC应用服务器，决定使用GBAPush为其与MTC设备之间的应用安全（即一个安全连接）建立密钥。PushNAF然后从BSF请求一个GBAPush-Inf（GPI）和一个Ks（ext/int）NAF密钥，并进一步将GPI发送到MTC设备。MTC设备处理GPI并生成一个Ks（ext/int）_NAF密钥。这样MTC设备和PushNAF可以使用共享的Ks（ext/int）NAF密钥保护Ua应用协议（即安全连接）。
如果PushNAF（MTC服务器或MTC应用服务器）与MTC设备之间无IP连接，GPI可以在触发信息中发送到MTC设备。在MTC服务器作为PushNAF的情况下作为触发信息的GPI通过Tsp接口发送。在MTC应用服务器作为PushNAF的情况下作为触发信息的GPI通过Tsms接口发送。GPI可以有两个用途：GPI可以为应用协议（即安全连接）提供密钥：GPI可以用于以端到端的方式保护触发信息。如果PushNAF（MTC服务器或MTC应用服务器）与MTC设备之间有IP连接，GPI可以在MTC应用使用的应用协议中发送，并为安全连接提供密钥。如何使用Ks_(ext/int)_NAF密钥保护MTC设备与MTC服务器之间或MTC设备与MTC应用服务器之间的通信依赖于使用的Ua应用协议。8USIM与MTC设备绑定安全技术要求8.1基于UE的USAT应用配对概述
本章针对如何绑定USIM与MTC设备进行了明确说明。该解决方案在UE和运营商网络中是可选的。为使UE有USAT应用配对能力，ME应支持USAT（USAT在3GPPTS31.111中规定）。8.2安全技术要求
当从终端取回的IMEI或IMEISV与经USAT配置的UICC的值或值的范围匹配时，USAT应用配对成功。如果终端不支持USAT命令PROVIDELOCALINFORMATIONUSAT应用配对失败。UICC重置后，在选择USIM应用前，USIM将PIN置于死锁状态。USAT配对成功后，PIN可处于解锁状态或禁用状态。支持USAT应用配对的UE进行Profile下载，该过程具体如3GPPTS31.111所规范。USIM随即发送一个主动命令PROVIDELOCALINFORMATION以请求UE的IMEI(SV)。然后，在开始USIM初始化过程前，UE发送携带IMEI(SV)的TERMINALRESPONSE消息。文件EFIMEISv保存IMEI(SV)或者与USIM绑定的值的范围。YD/T29132015
文件EFpairin保存由UICC执行的最后配对检查的状态。UICC检查USIM和MTC设备之间的组合，并在配对检查成功的情况下将状态标记设置为“OK”。UICC也在EFpairing文件中存储MTC设备的IMEI(SV)值。在配对检查失败时，USIM将状态标记设置为“OK”，并在EFpairing文件中存储未授权MTC设备的IMEI(SV)值。
保存在EFaairin文件中的配对检查的状态标记（其值为“OK或“KO’）可以由任何安装该UICC的终端读取。但是，保存在EFpairing文件中的IMEI(SV)值，通过ADM权利保护，只有运营商可以获取其信息。保存在EFpairing文件中的信息提供了一种检测USIM与MTC设备之间组合改变的机制。存储在EFpairing文件中的信息由维护人员在本地读取。UICCOTA机制（在3GPPTS31.115、3GPPTS31.116和ETSITS102.225、ETSITS102.226中规范）用于更新保存在USIM中的EFpairing文件。该机制通过增加或删除EFpairing文件中的授权IMEI(SV)值或IMEI(SV)范围，对USIM与MTC设备（s)的组合变更提供动态管理。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2913-2015
M2M通信系统增强安全要求
Securityaspectsofnetwork enhancementformachine-typecommunications
2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
规范性引用文件·
缩略语：
M2M安全架构和安全需求：
4.1M2M安全架构
安全需求
5Tsp接口安全技术要求
双向鉴权·
安全配置·
MTC终端触发相关安全技术要求.6
过滤设备触发SMS短消息的网络侧方案：6.2
安全连接技术要求
7.2MTC设备发起的安全连接
7.3网络发起的安全连接
8USIM与MTC设备绑定安全技术要求基于UE的USAT应用配对概述
安全技术要求
附录A（资料性附录）M2M应用场景·次
YD/T2913-2015
YD/T2913-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中兴通讯股份有限公司、中国信息通信研究院、华为技术有限公司、大唐电信科技产业集团。
本标准主要起草人：游世林、林兆骥、余万涛、崔媛媛、陈璟、应江威、艾明。
1范围
M2M通信系统增强安全要求
YD/T2913-2015
本标准规定了移动通信系统承载M2M业务时的触发安全、Tsp接口安全、安全连接以及USIM与MTC设备绑定4个方面的安全技术要求。本标准适用于基于3GPPR12承载M2M业务的包括终端、智能卡和系统设备在内的端到端移动通信系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPPTS23.040短消息技术实现（TechnicalrealizationoftheShortMessageService(SMS)）3GPPTS23.142短消息增值业务：接口和信令流程（Value-addedServicesforSMS（VAS4SMS)）；Interface and signalling flow)3GPPTS23.2043GPPIP接入下的短消息业务：阶段2（SupportofShortMessageService(SMS）overgeneric3GPPInternetProtocol (IP)access;Stage2)3GPPTS23.682分组数据网络与应用下设备通讯的架构增强（ArchitectureEnhancementstofacilitate communications with Packet Data Networks and Applications)3GPPTS29.368MTC-IWF与SCS之间的Tsp接协议（TspinterfaceprotocolbetweentheMTCInterworkingFunction (MTC-IWF)and ServiceCapabilityServer (SCS))3GPPTS31.111USIM应用工具箱（Universal SubscriberIdentityModule(USIM)ApplicationToolkit(USAT)\
3GPPTS31.115USIM应用工具箱安全包结构（Securedpacketstructurefor（Universal)SubscriberIdentityModule(U)SIMToolkitapplications)3GPPTS31.116USIM应用工具箱APDU结构，（RemoteAPDUStructurefor(U)SIMToolkitapplications）
3GPPTS33.220通用认证架构(GAA)之通用自举架构，（GenericAuthenticationArchitecture（GAA)；Generic Bootstrapping Architecture (GBA))3GPPTS33.223通用认证架构（GAA）之通用自举架构推送功能（GenericAuthenticationArchitecture(GAA);GenericBootstrappingArchitecture (GBA)Pushfunction)ETSITS102.225智能卡：基于UICC应用的安全包结构（SmartCards；SecuredpacketstructurefoUICCbasedapplications）
ETSITS102.226智能卡：基于UICC应用的远程APDU结构（Smartcards；RemoteAPDUstructureforUICCbasedapplications)
YD/T2913-2015
3缩略语
下列缩略语适用于本文件。
MTC-IWF
Attribute Value Pair
Capabilities-Exchange-AnswerCapabilities-Exchange-RequestEncapsulating Security PayloadGeneral Packet Radio ServiceInternet Key Exchange
Machine-Type Communication
MTC Interworking Function
Public key infrastructure
Service Capability Server
Transport Layer Security
Universal MobileTelecommunications SystemUSIMApplication Toolkit
UMTSSubscriberIdentityModuleUMTS Radio Access Network
User Equipment
UMTS Integrated Circuit Card4M2M安全架构和安全需求
4.1M2M安全架构
备注：T5a，T5b和T5c接口在本标准不做要求。图1定义了一个高层次的机器类通信安全架构。属性值对
能力交换响应
能力交换请求
封装安全有效负载
通用分组无线业务
Internet密钥交换协议下载标准就来标准下载网
机器类通信
机器类通信互联功能
公钥基础设施
业务能力服务器
传输层安全
通用移动通信系统
USIM应用工具
UMTS用户身份模块
UMTS无线接入网
用户设备
UMTS集成电路卡
层次A：MTC设备和3GPP网络之间机器类通信的安全可以进一步分为：AI：MTC设备和无线接入网络之间机器类通信的安全：A2：MTC设备和非接入层之间机器类通信的安全：A3：MTC设备和非3GPP接入之间机器类通信的安全。层次B：3GPP网络和SCS/MTC应用之间机器类通信的安全可以进一步分为：B1：在间接模式下SCS和3GPP网络之间的机器类通信的安全。可以进一步细分为当SCS位于3GPP网络域内与3GPP网络域外的安全。B2：在直接模式下MTC应用和3GPP网络之间的机器类通信的安全。SCS和MTC应用之间的通信在本标准规定范围之外。层次C：MTC设备和SCS/MTC应用之间机器类通信的安全可以进一步分为：C1：在间接模式下MTC服务器和MTC设备之间的机器类通信的安全。C2：在直接模式下MTC应用和MTC设备之间的机器类通信的安全。2
控制面
用户面
归属网络（3GPP网络）
拜访网络（3GPP网络）
M2M设备
4.2安全需求
4.2.1MTC安全需求
移动交
换中心
移动性管
理实体
GPRS克
特节点
短消息
MTC-IWF
分组数据网
服务网关
归属用户
服务器
图13GPPM2M安全架构
MTC认证
服务器
YD/T2913-2015
MTC应用
MTC应用
非直接模式?
直换模式
温合模式
针对MTC的安全需求包括：M2M的优化不能降低优化前通讯系统的安全级别。4.2.2Tsp接口安全需求
Tsp接口应符合如下安全需求：
Tsp接口之间的通讯应提供完整性保护、重放攻击保护、机密性保护和隐私保护：Tsp接口之间的通讯应提供相互认证、鉴权：相互认证的方式见3GPPTS29.368：Tsp接口应使用完整性保护和重放攻击保护；Tsp接口应使用机密性保护；
一Tsp接口应使用隐私保护（比如：IMSI不能传递到非3GPP运营网络之外）。4.2.3MTC-IWF安全需求
MTC-IWF的安全需求与Tsp接口安全需求一致。3
YD/T2913-2015
5Tsp接口安全技术要求
5.1概述
应使用在IETFRFC3588中所定义的Diameter安全机制。5.2双向鉴权
本标准只针对如下部署方式的Tsp接口安全过程：MTC-IWF和SCS之间的Tsp接口上的DIAMETER消息应通过MTC-IWF所在的安全域中的至少一个DIAMETER代理（后文中称为“MTC-IWF侧代理\），和SCS所在的安全域中的一个DIAMETER代理（后文中称为“SCS侧代理\）。也可以有其他的部署方式，但不推荐使用Tsp接口。注1：
MTC-IWF所在的的安全域中的一个节点和SCS所在的安全域中的一个节点之间的双向鉴权应使用IETFRFC3588所定义的TLS或IPsec，除非使用6.3.3中所定义的安全配置。应遵循以下规则：
在MTC-IWF的安全域和SCS的安全域之间不能有存在中间DIAMETER代理的第三个安全域。一在MTC-IWF的安全域中，如果有MTC-IWF侧代理，则由MTC-IWF侧代理作为执行Tsp相关双向鉴权的节点；如果没有MTC-IWF侧代理，则由MTC-IWF作为执行Tsp相关双向鉴权的节点。在SCS的安全域中，如果有SCS侧代理，则由SCS侧代理作为执行Tsp相关双向鉴权的节点：如果没有SCS侧代理，则由SCS作为执行Tsp相关双向鉴权的节点。一各节点应使用TLS或IPsec验证在CER/CEA消息中收到的标识（比如，证书中的名称）的节点标识。一域授权检查：一个收到Tsp相关DIAMETER消息的适当的节点应检查该消息的发出者，即在应用层指定的SCS（或MTC-IWF），是真正被授权通过其标识在之前的步骤中被验证的节点发送该消息的。这项检查可以通过与SCSs（或MTC-IWFs）相关联的本地表格结合其标识可以被接受域验证的初始安全域中的节点执行。执行该域授权检查的节点应是MTC-IWF或发到MTC-IWF的消息的MTC-IWF侧代理，以及SCS或发到SCS的消息的SCS侧代理。注2：
即使存在MTC-IWF侧代理，MTC-IWF也可以执行域安全检查，因为MTC-IWF侧代理在Record-RouteAVP中包含验证过的标识（SCS侧的情况类似）。域授权检查的概念在以上的列举项中定义，而不是来自其他规范性文档。5.3安全配置
在TLS上支持Tsp是强制的。支持IKE/IPsec是可选的。IKE、IPsec和TLS的安全配置应遵循以下规定：一TLS实现和使用的配置应遵循3GPPTS33.310附录E中的规定。双向鉴权应基于根据3GPPTS33.310中6.1.3a节和6.1.4a节的配置的证书。用于这些证书的PKI的结构不在本标准范围内，因此本条中对证书的发出者的规定不适用。
如果支持IKE/IPsec，则实现IKEv2和基于根据3GPPTS33.310配置的证书的双向鉴权是强制的。证书配置应遵循3GPPTS33.310中6.1.3和6.1.4。用于这些证书的PKI的结构不在本标准范围内，因此本条中对证书的发出者的规定不适用。一如果支持IKE/IPsec，则IPsecESP应根据3GPPTS33.210中的配置实现。隧道模式是强制支持的。传输模式是可选支持的。
6MTC终端触发相关安全技术要求6.1概述
YD/T2913-2015
MTC终端触发安全技术方案是基于SMS短消息传递的设备触发消息的过滤的相关技术要求。6.2过滤设备触发SMS短消息的网络侧方案以下方案用于过滤基于SMS短消息传递的设备触发消息。该方案依赖于短消息中的标准化标识，也就是3GPPTS23.040中所定义的TPProtocolID，用于区分触发短消息和其它类型的短消息。该方案进一步假设合法触发短消息的传递需要经过归属域网络中的SMS-SC，以验证通过Tsms接口发送触发短消息的短消息实体身份是否合法；或者经过归属域网络中的MTC-IWF，以验证通过Tsp接口发送触发SM的SCS身份是否合法。归属域网络应该基于3GPPTS23.040，为发给归属域网络用户的短消息终呼实现归属网络路由，以保护这些用户免遭未授权SMS触发消息的攻击（例如，支持SMS触发的终端中的签约）。归属网络路由应该能够将SM传递给HPLMN中的SMS路由器，而不是传递给目标UE的服务MSC/VLR、SGSN、或者MME。如果SMS路由器接收到的SM不是来自于归属域网络中的处理SMS触发消息的SMS-SC，则SMS路由器会将该SM发送给过滤设施，从而过滤并阻止包含触发指示的短消息。参考3GPPTS23.040和3GPPTS23.204所定义的SMS架构和功能，SMSs的传输需要经过SMS-SC。根据M2M机器类通信的架构，对于基于SMS的设备触发，SMS-SC所接收的短消息包含了相关的发送者标识和接收者标识，这些短消息来自三条路径，即通过Tsms接口的短消息实体、T4接口、SMS-IWMSC。过滤SMS触发消息是基于网络侧的，因此伪造的SMS触发消息应该被SMS-SC所识别并阻止。以下描述了SMS-SC如何处理来自于这三条路径的短消息。一如果HPLMN中处理SMS触发消息的SMS-SC所接收的SM不是来自于T4接口，则应该将该SM发送给过滤设施。
一如果过滤设施所接收的SM包含触发指示并且不是源于一个授权发送触发SMs的可信SME，则阻止该SM。
一如果过滤设施所接收的SM包含触发指示并且源于一个授权发送触发SMs的可信SME，则将触发请求SM发送给SME所授权发送的特定UEs。本标准不定义过滤设施如何决定可信SME是否允许将设备触发SM发送给特定的UE。
一如果SMS-SC所接收的SM来自于T4接口的MTC-IWF，则SMS-SC认为T4接口是可信的并继续发送该SM，因为MTC-IWF能认证MTC服务器并且能保证只有授权了的MTC服务器才可以触发特定的MTC设备。
一如果SMS-SC所接收的SM来自于SMS-IWMSC，则SMS-SC应该将SM发送给过滤设施。这样，SMS-SC可以通过检查接收方的授权发送方列表，来决定SM是否来自于一个授权的SME。如果不是，SMS-SC阻止该伪造触发SM的发送。如果MTC-IWF接收的触发请求来自于Tsp接口，则MTC-IWF应该过滤并阻止来自非可信SCS的触发SM，3GPPTS23.682的5.2.1节描述了具体流程。根据3GPPTS23.040的9.2.3.9节，普通UE不允许发送起呼触发短消息来触发MTC设备，因此SMS-SC应该根据普通UE的签约信息来区分并阻止伪造的MO设备触发SMSs根据运营商策略，可信源可以被授权发送触发消息给任何UB。为了防止源欺骗，需要保护用来传5
YD/T2913-2015
输触发消息的接口，特别应该保护Tsms、Tsp、和T4接口。3GPPTS23.682的4.3.3.1节中定义了Tsp接口安全，Tsms接口的安全机制不在本标注研究范围内。可以根据3GPPTS23.142定义的架构来过滤非法SMS。当过滤实体接收到SM后，它能够基于包含在SM中的触发指示（即，3GPPTS23.040定义的TPProtocolID）来识别SM是否为触发SM。上述解决方案中的过滤功能分布于SMS路由器上的过滤设施、SMS-SC上的过滤设施、以及MTC-IWF上的过滤设施。这说明过滤功能需要由能够在本地连接接口上验证SM源的实体所激活。同时SMS路由器只仅仅是MT场景下的一个可选实体，它没有能力验证Tsp和Tsm接口上的消息源，因此只在SMS路由器上实现过滤功能是不足的。实现过滤功能设施的最好位置是SMS-SC，因为它可以过滤来自三条路径的SMs。
解决方案旨在防止未授权实体发送大量的触发消息给大量的MTC设备而造成对核心网的分布式拒绝服务攻击。但是，本方案只是防止了SMS应用层威胁，而没有能够防止网络内部节点或网络信令链接遭受威胁或攻击者滥用所带来的攻击（例如，欺骗的MAP_ForwardShortMessage包含一个触发指示并通过SS7连接发送给目标UEs）。如果需要消除这种攻击或者HPLMN不支持归属网络路由，那么本章的安全解决方案是不足的，因此需要在网络侧的MTC应用和UE的MTC应用之间，实现某种端到端的密码保护机制来保护触发消息。但这种解决方案可能由应用层来提供而不在本标准范围之内。将来的3GPF版本可能还会引入这种密码保护触发消息的解决方案。存在不同网络的短信中心直接连接的场景，因此部署归属网络路由不是强制的。7安全连接技术要求
7.1概述
MTC安全连接特征就是运营商能够为保护MTC设备和SCS之间（非直接模式下）或者MTC设备和MTC应用之间（直接模式下）的应用协议安全提供密钥材料。GBA，如3GPPTS33.220所描述的，用于针对基于3GPPAKA机制的应用安全的自举认证和密钥协商。GBA应被用于为一个MTC设备发起的安全连接建立密钥。作为GBA的扩展，GBAPush在3GPPTS33.223中进行了定义。GBAPush也用于为两个实体间的应用安全建立密钥。
其他机制（例如，在不能应用GBA的场景中使用EAP-AKA）可以用于为MTC设备和MTC服务器之间或者MTC设备和MTC应用服务器之间提供安全连接特征。这些机制被认为不在本标准范围内。在ME和网络之间的安全连接特征实现是可选的。7.2MTC设备发起的安全连接
UE发起的安全连接仅适用于支持HTTP协议的MTC设备。一个MTC设备发起的安全连接应通过3GPPTS33.220定义的GBA方式建立。MTC设备与MTC服务器或者MTC设备与MTC应用服务器之间的安全连接都应使用GBA方式。MTC服务器和MTC应用服务器应作为NAF服务器使用。通过GBA方式建立安全连接密钥的过程具体如下：MTC设备与BSF通过Ub接口执行GBA自举过程。自举过程使得MTC设备和BSF获得一个共享密钥Ks和与该共享密钥Ks关联的一个标识B-TID。MTC设备接着基于Ks生成一个Ks_(ext/int)NAF密钥，并通过Ua接口与目标NAF建立一个连接。在非直接模式下，NAF功能由MTC服务器执行，在直接模式下，NAF6
YD/T2913-2015
功能由MTC应用服务器执行。开始通信时，MTC设备向NAF提供B-TID。NAF向BSF请求B-TID关联的Ks_（ext/int）NAF密钥。这样，MTC设备与MTC服务器/MTC应用服务器就可以使用Ks_（ext/int）NAF密钥保护Ua应用协议（即安全连接）。如何使用Ks_（ext/int）NAF密钥保护MTC设备与MTC服务器之间或MTC设备与MTC应用服务器之间的通信依赖于使用的Ua应用协议。7.3网络发起的安全连接
一个网路发起的安全连接应通过3GPPTS33.223定义的GBAPush方式建立。MTC设备与MTC服务器或者MTC设备与MTC应用服务器之间的安全连接都应使用GBAPush方式。MTC服务器和MTC应用服务器应作为PushNAF服务器使用。通过GBAPush方式建立安全连接密钥的过程具体如下：
PushNAF服务器，即非直接模式下的MTC服务器和直接模式下的MTC应用服务器，决定使用GBAPush为其与MTC设备之间的应用安全（即一个安全连接）建立密钥。PushNAF然后从BSF请求一个GBAPush-Inf（GPI）和一个Ks（ext/int）NAF密钥，并进一步将GPI发送到MTC设备。MTC设备处理GPI并生成一个Ks（ext/int）_NAF密钥。这样MTC设备和PushNAF可以使用共享的Ks（ext/int）NAF密钥保护Ua应用协议（即安全连接）。
如果PushNAF（MTC服务器或MTC应用服务器）与MTC设备之间无IP连接，GPI可以在触发信息中发送到MTC设备。在MTC服务器作为PushNAF的情况下作为触发信息的GPI通过Tsp接口发送。在MTC应用服务器作为PushNAF的情况下作为触发信息的GPI通过Tsms接口发送。GPI可以有两个用途：GPI可以为应用协议（即安全连接）提供密钥：GPI可以用于以端到端的方式保护触发信息。如果PushNAF（MTC服务器或MTC应用服务器）与MTC设备之间有IP连接，GPI可以在MTC应用使用的应用协议中发送，并为安全连接提供密钥。如何使用Ks_(ext/int)_NAF密钥保护MTC设备与MTC服务器之间或MTC设备与MTC应用服务器之间的通信依赖于使用的Ua应用协议。8USIM与MTC设备绑定安全技术要求8.1基于UE的USAT应用配对概述
本章针对如何绑定USIM与MTC设备进行了明确说明。该解决方案在UE和运营商网络中是可选的。为使UE有USAT应用配对能力，ME应支持USAT（USAT在3GPPTS31.111中规定）。8.2安全技术要求
当从终端取回的IMEI或IMEISV与经USAT配置的UICC的值或值的范围匹配时，USAT应用配对成功。如果终端不支持USAT命令PROVIDELOCALINFORMATIONUSAT应用配对失败。UICC重置后，在选择USIM应用前，USIM将PIN置于死锁状态。USAT配对成功后，PIN可处于解锁状态或禁用状态。支持USAT应用配对的UE进行Profile下载，该过程具体如3GPPTS31.111所规范。USIM随即发送一个主动命令PROVIDELOCALINFORMATION以请求UE的IMEI(SV)。然后，在开始USIM初始化过程前，UE发送携带IMEI(SV)的TERMINALRESPONSE消息。文件EFIMEISv保存IMEI(SV)或者与USIM绑定的值的范围。YD/T29132015
文件EFpairin保存由UICC执行的最后配对检查的状态。UICC检查USIM和MTC设备之间的组合，并在配对检查成功的情况下将状态标记设置为“OK”。UICC也在EFpairing文件中存储MTC设备的IMEI(SV)值。在配对检查失败时，USIM将状态标记设置为“OK”，并在EFpairing文件中存储未授权MTC设备的IMEI(SV)值。
保存在EFaairin文件中的配对检查的状态标记（其值为“OK或“KO’）可以由任何安装该UICC的终端读取。但是，保存在EFpairing文件中的IMEI(SV)值，通过ADM权利保护，只有运营商可以获取其信息。保存在EFpairing文件中的信息提供了一种检测USIM与MTC设备之间组合改变的机制。存储在EFpairing文件中的信息由维护人员在本地读取。UICCOTA机制（在3GPPTS31.115、3GPPTS31.116和ETSITS102.225、ETSITS102.226中规范）用于更新保存在USIM中的EFpairing文件。该机制通过增加或删除EFpairing文件中的授权IMEI(SV)值或IMEI(SV)范围，对USIM与MTC设备（s)的组合变更提供动态管理。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。