【YD通讯标准】 移动增值业务公共安全框架和安全功能

ICS33.030
中华人民共和国通信行业标准
YD/T2852-2015
移动增值业务公共安全框架和安全功能Technical requirement of securitycommonfunctionsformobilevalueaddedservices
2015-04-30发布
2015-07-01实施
中华人民共和国工业和信息化部发布前言·
1范围
2规范性引用文件
3术语、定义和缩略语
3.1术语和定义
3.2缩略语
4概述
5体系结构
5.1体系结构模型
5.2SEC_CF基本流程·
5.3SEC_CF部署
6适合SEC.CF的TLS特征·
6.2TLS特征
7适合SEC_CF的3GPPGBA特征：
7.1概述
7.2OMAGBAProfile
附录A（资料性附录）应用场景
附录B（资料性附录）
应用场景
参考文献·
YD/T2852-2015
YD/T2852-2015
本标准按照GB/T1.1-2009给出的规则起草。本标准参考了OMA引擎SEC_CF规范OMA-ERP-SEC_CF-V1_0-20080902-A。本标准由中国通信标准化协会提出并归口。本标准起草单位：上海贝尔股份有限公司、工业和信息化部电信研究院、中国移动通信集团公司、杭州摩托罗拉移动通信设备有限公司、中国移动通信集团设计院有限公司、南京爱立信熊猫通信有限公司。
本标准主要起草人：胡志远、朱红儒、崔媛媛、刘利军、刘斐、高
岩、杜雪涛、南明凯。
HiiKAoNiKAca
1范围
移动增值业务公共安全框架和安全功能YD/T2852-2015
本标准规定了移动增值业务公共安全框架和安全功能，包括体系结构、适合SECCF的TLS特征和适合SEC_CF的3GPPGBA特征等。
本标准适用于采用客户一服务器运作模式并使用TCP协议进行传输的OMA业务引擎。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。3GPPTS 24.109
3GPPTS29.109
3GPPTS33.220
3GPPTS33.221
3GPPTS33.222
3GPP2 S.S0109-0
3GPP2S.S0114
IETFRFC793
IETFRFC2246
IETFRFC2406
IETFRFC2459
IETFRFC2617
IETFRFC2817
IETFRFC2818
IETFRFC4279
IETFRFC4301
IETFRFC4346
自举接口Ub和网络应用接口Ua的协议部分（Bootstrappinginterface（Ub）andnetwork application function interface (Ua), Protocol details)基于Diameter协议的Zh和Zn接口（ZhandZnInterfaces based on theDiameterprotocol)
通用自举（bootstrapping）框架（GenericBootstrappingArchitecture）签约用户证书的支持（SupportforSubscriberCertificates）使用HTTPS访间网络应用功能（Accesstonetworkapplicationfunctionsusingsecurehypertexttransferprotocol (HTTPS)通用自举（bootstrapping）框架（GenericBoostrappingArchitecture（GBA）Framework)
使用GBA的安全机制（SecurityMechanismsusingGBA）传输控制协议（TransportControlProtocol)）传输层安全(TransportLayerSecurity(TLS）Version1.0)因特网封装安全净荷（IPEncapsulatingSecurityPayload（ESP）因特网X.509公钥基础设施证书和证书撤销列表(IntermetX.509PublicKeyInfrastructureCertificateand CRLProfile)HTTP Digest认证 (HTTP Authentication: Basic and Digest Access Authentication)在HTTP/1.1中升级到TLS（UpgradingtoTLSWithinHTTP/1.1）基于传输层安全的HTTP（HTTPOverTLS）基于预共享密钥的传输层安全（Pre-SharedKeyCiphersuitesforTransportLayerSecurity (TLS))
因特网协议的安全架构（SecurityArchitecturefortheInternetProtocol）传输层安全（TransportLayerSecurity（TLS）Version1.1）HiiKANiKAca
YD/T2852-2015
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。请求资源RequestingResource
OMAEnabler中网络侧功能。在SUPL(SecureUserPlaneLocation）中请求资源可以对应到SLP（SUPLLocation Platform)
3.2缩略语
下列缩略语适用于本文件。
PSK-TLS
(R)UIM
SEC-CF
the Third Generation Partnership Projectthe Third Generation Partnership Project 2Authentication and Key AgreementBootstrapping Server FunctionDevice Management
Denial of Service
Fully Qualified Domain Name
Generic Authentication ArchitectureGeneric Bootstrapping ArchitectureHome Location Registry
Home Subscriber System
Hyper Text Transport ProtocolHTTP overTLS
Internet Engineering Task ForceIP Multimedia Service
IPSecurity
IP Multimedia Services Identity ModuleKey Management Center
Mobile Network Operator
Management Objects
Mobile Terminal
Network Application FunctionOpen Mobile Alliance
OMA Security Gateway
Pre-Shared Key TLS
(Removable) User Identity ModuleStatic Conformance RequirementsSecurityCommonFunctionforMobileApplicationSecurity Agent
第三代合作伙伴计划
第三代合作伙伴计划2
认证和密钥产生协议
Bootstrapping功能
设备管理
拒绝服务
完全合格域名
通用认证架构
通用Bootstrapping架构
归属地位置注册中心
归属地用户系统
超文本传输协议
基于TLS的HTTP
因特网工程工作小组
IP多媒体业务
IP安全
IP多媒体业务识别模块
密钥管理中心
移动网络运营商
管理对象
移动终端
网络应用功能
开放移动联盟
OMA安全网关
预共享密钥TLS
（可移动）用户标识模块卡
静态兼容需求此内容来自标准下载网
移动应用公共安全功能
安全代理
iiKAoiKAca
4概述
SubscriberIdentityModule
TransmissionControlProtocol
Transport Layer Security
User Datagram Protocol
Universal Integrated CircuitCardUniversalMobileTelecommunicationsSystemUniversal SubscriberIdentityModule用户身份识别模块
传输控制协议
传输层安全
数据报协议
通用集成电路芯片
通用移动通信系统
YD/T2852-2015
通用用户身份识别模块
公共安全功能框架（SECCF）的目的是提供一系列公共通用的安全机制，并根据这些安全机制提供一些能为各OMA业务引擎所重用的可能的部署。该标准的基本原理是尽可能的避免为每个需要安全功能的OMA业务引擎开发各自安全功能而带来的重复劳动。在开发新OMA业务引擎时，公共安全功能框架提供了结构实体（如安全网关等）的重用和安全规范（如协议特征）的重用。该版本SECCF的目的是为那些采用客户-服务器运作模式并使用TCP协议（见IETFRFC793)进行传输的OMA业务引擎提供安全功能。在SEC_CF上下文中的客户-服务器运作模式要求有一个从应用服务器请求服务的安全代理（如可在移动终端上实现）。通常情况下，一个安全代理可在一个移动终端上实现，一个应用服务器可能是一个诸如位置业务服务器、计费单元等位于网络侧的OMA业务引擎中的某组成部分。
SECCF定义了诸如安全网关等功能实体，为了提供安全服务，这些功能实体能集成到OMA业务引擎框架中一些功能实体中（如移动终端、应用服务器等）。为能适应目前网络和业务提供商已建立的部署模式（如归属网络、拜访网络等），SECCF阐述了不同的部署模型。SEC_CF定义了几个功能实体之间的接口，这些功能实体能使用工业标准的安全协议来实现。在有些情况下为避免生成新的接口和简化实现方案，SECCF功能实体也能集成到业务引擎的自身功能实体中。OMA业务引擎规范与SEC.CF的成功融合/集成需要对安全需求进行分析并映射到最适合的SEC_CF部署模式中。大多数情况下，SECCF不能作为一个业务引擎规范已完成后的叠加模块。所以，业务引擎规范的开发过程中应尽早考虑融合SEC_CF以便尽可能地避免框架上的不一致性。该安全引擎定义了一些能为其他OMA业务引擎重用的安全特征，如认证、机密性保护、完整性保护等。
5体系结构
5.1体系结构模型
SECCF由结构化的组件和这些组件之间的接口组成。图1显示了SECCF所定义的结构化组件及相应的接口
请求资源
OMA安全网关
（OsG)
安全代理
(SECA)
图1SEC_CF体系结构
iiikAoNiAca
YD/T2852-2015
SECCF定义了如下几个结构化组件安全代理（SECA）：通过该实体，应用或用户能与请求资源进行交互。对于用户，这可通过用户接口UI来执行。一个移动终端可以实现一个安全代理，通常该移动终端包括一个诸如(U)SIM或R-UIM的可拆卸的安全Token（令牌）卡。然而，如果没有可拆卸的安全Token卡，SECCF也支持实现在应用服务器上的安全代理。通常，SECCF中的安全代理代表用户，并且SECA中的所有标识都与用户签约身份绑定在一起。目前，安全上下文信息不使用MT的设备标识。安全代理提供以下功能：·提供接口可与可拆卸的安全Token卡通信，如与3GPP的(U/SIM卡或3GPP2的R-UIM卡进行通信：
·提供唯一的身份标识：
·使用必要的密钥素材执行安全服务：·处理用于SECCF操作的诸如密钥素材的安全凭证：·执行认证、机密性保护、完整性保护等安全服务，还能提供防DoS攻击服务：·能与归属或拜访OSG进行通信。-OMA安全网关（OSG）：为使用SECCF的OMA业务引擎提供诸如认证、加密、完整性保护等安全服务。OSG完全能集成到业务引擎本身中，也可部署成一个独立实体，该独立实体能为许多通过OSG可达的业务引擎提供安全服务。OMA安全网关提供如下功能：·为与之连接的请求资源提供SECCF所定义的所有安全服务，如认证、授权、机密性保护、完整性保护、防重播攻击等：
·提供防DoS攻击服务。
SECCF中结构化组件之间的接口定义如下：SEC-1：SECA和安全网关OSG之间的接口。目前SECCF在该接口上只能支持TCP作为传输协议。在客户-服务器模式中，如果请求资源选择一个在TCP上实现的特定的应用协议，则该协议能通过SEC-1上的安全机制进行保护。该接口的安全服务能在传输层和应用层上实现。该接口应至少支持TLS（见IETFRFC2246），在传输层安全向SECA提供OSG认证。如果使用了HTTP，则HTTPDigest应用于向OSG提供SECA认证。如果该接口上没使用HTTP，则为了在传输层上提供OSG和SECA之间的相互认证应支持PSK-TLS和/或客户证书。-SEC-2：各OSG之间的接口。该接口用于分布式业务引擎部署，在此SECA通过归属OSG连接拜访域的资源。
该接口应至少支持TLS和应支持隧道模式的IPSEC（见IETFRFC4301）且其机密性保护和完整性保护符合IETFRFC2406。
-SEC-3：指OSG和没集成过OSG的所请求资源之间的接口。SECCF对以下协议进行裁剪和重用：IETFTLS(TransportLayerSecurity)（见IETFRFC4346)IETFPSK-TLS(Pre-SharedKeyCiphersuites forTransportLayer Security)（见IETFRFC4279)-IETFHTTPDigestAuthentication（见IETFRFC2617)-IETFIPSec(InternetSecurityArchitecture)（见IETFRFC4301)4
HiiKAoNiKAca
YD/T2852-2015
以上描述了SECCF体系结构模型。相关应用场景见附录A。为了便于理解，附录B中描述了如何将SEC_CF中的逻辑实体和相关接口映射到SUPL体系结构中。5.2SEC_CF基本流程
基本的SECA初始化流程如图2所示。SECA
建立(PSK-）TLS
HTTPDigest客户端认证
消息3
请求Enabler资源（SECAId）
消息6
接受资源请求
消息！
请求认证凭证（SECAId）
消息2
认证凭证
消息4
请求Enabler资源(SECAId）
消息5
接受资源请求
图2SECA启动的基本流程
请求资源
在用户向其他OMA业务引擎请求资源访问之前，需要在SECA和OSG之间启动建立TLS或PSKTLS安全隧道。SECA和OSG之间相互认证有3种情况：1）基于共享密钥的PSK-TLS：2）认证服务器使用证书，认证SECA使用HTTPDigest：3）服务器和客户端都使用证书认证。图2描述了由SECA启动的基本认证流程，具体认证步骤描述如下：在用户向其他OMA业务引擎请求资源访问之前需要建立TLS或PSKTLS安全隧道，于是SECAC代表用户）启动认证流程：
a）OMA安全网关（OSG）发送消息1给密钥管理中心（KMC），目的是根据用户的SECAId向KMC请求认证凭证（如密钥、证书等）：b）KMC通过消息2向OSG返回用户的认证凭证：C）根据用户的认证凭证，OSG认证SECA，认证方式可以是HTTPDigest或PSKTLS。同时SECA也需要认证OSG，认证方式可以是OSG的证书或PSKTLS。如果在OSG和SECA之间都采用证书认证方式，则消息1和消息2可以省略；d）认证成功后，SECA发送消息3给OSG，用以请求OMA业务引擎的资源，该消息包含用户标识SECAId:
e）OSG转发消息4给OMA业务引擎请求资源，该消息包含用户标识SECAId；f）请求资源返回确认消息5给OSG，确认接受用户的资源请求；g）OSG转发确认消息6给SECA，向用户确认请求资源已接受其请求。5.3SEC_CF部署
5.3.1SECCF部署
SECCF充许SECA能通过归属OSG安全访问拜访域资源或通过拜访OSG直接访问拜访域资源。5
HiiKAoNiKAca
YD/T2852-2015
SECCF的特定部署可能依赖于OMA业务引擎的特定操作需求和底层的IP传输模式。针对以下的部署场景，引入了一些额外的网元和接口：密钥管理中心KMC提供如下功能：·为（归属/拜访网络的）OSG提供密钥管理支持：·为SECA提供密钥管理支持：
·KMC能集成到OSG。
KMC-IF接口：该接口连接OSG和KMC。注：在SEC_CFv1.0中，主要考患基于GBA的部署情况。部署一：直接访问OSG
该情况下，用于SECA密钥管理的GBA将有一个额外的接口到KMC（GBA中的BSF），即GBA中的Ub接口，见图3。
密钥管理中心
KMC-IF
请求资源
OMA安全网关
安全代理
(SECA)
图3直接访问OSG的部署
部署二：基于代理访问OSG
对于基于GBA的SECCF部署，只有代理模式是可行的。归属OSG作为拜访域中OMA业务引擎的代理。归属OSG在归属和拜访OSG之间应通过SEC-2接口提供安全连接，见图4。归属域
5.3.2引擎协议需求
对引擎协议有如下要求：
引擎协议应基于TCP协议：
（属）
KMC-IF
（归属）
HSEC-2
（拜访）
图4基于代理访问OSG
引擎协议应以客户端-服务器方式操作。6
拜访域
请求资源
HiiKAoNiKAca
6适合SECCF的TLS特征
6.1概述
YD/T2852-2015
TLS（TransportLayerSecurity）在通信双方之间提供一个安全可靠的传输机制。它还可以依照不同的实现方式提供单向或双向认证。TLS工作于客户端-服务器模式，发起方称为客户端，响应方称为服务器。大多数情况下，TLS客户端可以用公钥证书认证TLS服务器。使用公钥证书或共享密钥（PSK-TLS）还可能实现双向认证。
TLS可以用来为承载层之上的协议，例如HTTP协议，提供安全保护。目前的TLS规范要求操作在可靠的传输协议之上，例如TCP协议。本标准目的是提供一个共同的TLS协议实现，使其适用于所有OMA业务引擎。制定一个安全且可互操作的共同的TLS实现规范，而无需在每个OMA引擎的规范中再分别定义其相关的安全需求。建议那些想要采用TLS安全传输机制的OMA引擎的开发者使用本标准来制定TLS实现的需求。本标准还定义了OMA引擎如何通过HTTP代理实现TLS隧道。6.2TLS特征
OMATLSProfile基于规范TLS1.0（见IETFRFC2246）。所有遵从OMA的TLSProfile实现应遵从TLS1.0规范。本标准制定了TLS1.0和其他可和TLS1.0共用的规范（例如PSK-TLS）的一个具体应用。PSK-TLS的实现应遵从PSK-TLS规范。本节的规范性描述是现有TLS和其相关规范的扩展。本节所有的术语须放在TLS1.0及其相关规范的上下文中去理解。
6.2.1支持TLS的加密工具
服务器应支持以下加密工具：
-TLS_RSA_WITH_3DES_EDE_CBC_SHA：-TLSRSA_WITHAESEDE_CBC_SHA。客户端应支持以下加密工具：
TLSRSAWITHAESEDECBCSHA：
-TLSRSA_WITH_NULL_SHA。
客户端宜支持TLSRSA_WITH3DESEDECBCSHA6.2.2支持PSK-TLS的加密工具
如果要支持PSK-TLS，应满足以下关于加密工具的需求。服务器应支持下列加密工具：
TLS_PSK_WITH_AES_128_CBC_SHA:-TLSPSK_WITH3DES_EDE_CBCSHA。客户端应支持以下加密工具之一-TLSPSKWITHAESI28CBCSHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA。6.2.3会话重起
客户端和服务器应支持TLS中定义的会话重起。会话生命期应长一些（例如12小时）。具体应参照TLS1.0中的相关指导。
YD/T2852-2015
6.2.4服务器认证
客户端和服务器须支持TLS1.0服务器认证。服务器须支持\WAP证书和CRLProfile\中所述的X.509服务器证书。客户端应遵从IETFRFC2818（3.1节）所述的服务器标识指导。另外，客户端应参考关于处理X.509服务器证书的指导，包括中描述的未知属性和扩展的处理。服务器应使用应用于WAP的X.509服务器证书，也可同时使用X.509服务器证书（见IETFRFC2459）如果支持PSK-TLS，客户端和服务器之间的双向互认证可使用共享密钥实现。6.2.5客户端认证
服务器应支持客户端认证。如果支持客户端认证，服务器须支持使用于WAP的X.509的客户端证书和X.509客户证书（见IETFRFC2459）。服务器还须在证书请求中包含RSA证书类型（即，rsa_sign）（见IETFRFC2246），且支持RSA用户证书和签名的验证。客户端可能支持客户认证。如果支持客户认证，客户端应支持WAP的X.509客户证书，且应能支持IETFRFC2459的X.509证书。客户端应支持RSA客户证书和签名。CA应发放WAP的X.509客户证书。如果支持PSK-TLS，客户端和服务器的互认证可以用共享密钥实现，前提是共享密钥只由两个端点共享。
6.2.6TLS隧道
使用TLS协议的客户端和服务器之间可能有HTTP代理。为了保证有代理介入时的端到端的传输层安全，发起服务器和客户端之间应使用隧道。客户端在使用HTTP代理时应支持TLS隧道。为了建立TLS隧道，客户端应使用HTTPCONNECT方法，见IETFRFC2817。此外，客户端只能在一个原始TCP连接上建立隧道，不可在已升级（\upgraded\）的连接上建立隧道，见IETFRFC2817。HTTP代理应支持IETFRFC2817所描述的HTTPCONNECT方法。注意，在一个TLS隧道上可能介入多个HTTP代理服务器，包括不支持HTTP的代理服务器。客户端不应假定TLS隧道一定能建立成功。在得到不成功HTTPCONNECT响应后，客户端须放弃建立TLS隧道的尝试。
7适合SECCF的3GPPGBA特征
7.1概述
GBA（通用Bootstrapping架构）（见3GPPTS33.220.）提供了一种安全可靠的方法来建立一个在客户端和服务器端间的安全关联。GBA利用一个长期的安全关联，该长期的安全关联储存在客户端的防算改模块中和核心网网元中（比如：归属地位置注册中心HLR）或者移动网络运营商（MINO）的归属地用户系统HSS中）。一个典型的防算改设备是一个智能卡或者一个通用集成电路芯片（UICC）。基于这种长期的安全关联，一个短期的服务器端专用关联，比如GBA证书，会在Bootstrapping过程中，在客户端和移动网络运营商控制的Bootstrapping服务功能（BSF）专用网络元件之间建立。只要该网络应用功能（NAF）的应用业务运营商与MNO之间有BSF的协议，这个GBA证书将应用于该客户端和该服务器之间的通信。客户端和用户端根据需要使用这个短期安全关联，比如：在HTTPDIGEST认证（HTTPDigestauthentication）中将它作为用户名和密码，或者在PSK-TLS中作为预共享秘密。本标准的目标是为GBA提供一种能被所有的经OMA引擎使用的公共GBA规范。该目的是创建一个安全的和具有互操作性的通用GBA，它可以被重复使用而无需在每个经OMA引擎的规范中分别定义。8
7.2OMAGBAProfile
7.2.1概述
YD/T2852-2015
OMAGBA基于3GPPGBA（见3GPPTS33.220），3GPP2GBA（见3GPP2S.S0109）和其他相关规范。遵从本标准的GBA实现应至少遵从以下规范：3GPPGBA规范（见3GPPTS33.220、3GPPTS33.221、3GPPTS33.222、3GPPTS24.109、3GPPTS29.109）：
3GPP2GBA规范（见3GPP2S.S0109、3GPP2S.S0114）本标准描述了一个以下GBA的特定实现：3GPPGBA、3GPP2GBA和能与GBA一同使用的相关规范，如Digest认证和PSK-TLS。
本章标准化的文本应认为是以上所述的3GPPGBA规范和3GPP2GBA规范的补充。7.2.2Bootstrapping机制
服务器端若支持3GPP终端应能使用通过下面任一种Bootstrapping机制获得的GBA认证凭证：基于GBA且没有USIM或者ISIM的（如3GGBA），在3GPPTS33.220中有详尽说明：一基于GBA且有USIM或者ISIM的（如3GGBA_U），在3GPPTS33.220中有详尽说明基于SIM的GBA（如2GGBA），在3GPPTS33.220及后续版本中有详尽说明。服务器端若支持3GPP2终端应能使用通过下面方式之一获得GBA认证凭证：基于GBA但没有UIM或者UICC的（如3GGBAME），在3GPP2S.S0109中有详尽说明：基于GBA且有UIM或者UICC的（如3GGBAU），在3GPP2S.S0109中有详尽说明。服务器与3GPP2GBAU或3GPP2GBAME的终端的交互和与3GPPGBA_U或3GPPGBAME的终端的交互是一致的。
3GPP客户端应支持以下GBA方式之一：基于GBA但没有USIM或基于GBA且有USIM或者ISIM的（如：3GGBA和3GGBA_U）在3GPPTS33.220中有详尽说明；基于SIM的GBA（如2GGBA）：在3GPPTS33.220及后续版本中有详尽说明。3GPP2客户端应支持以下GBA方式之一：需运行AKA的基于GBA且有UIM或UICC的，或基于GBA但没有UIM或UICC的，在3GPP2S.S0109中有详尽说明：
需运用MN-AAA密钥的基于GBA且有UIM或UICC的，或基于GBA但没有UIM或UICC的，在3GPP2S.S0109中有详尽说明；一需运用CAVE的基于GBA但没有UIM或UICC的，在3GPP2S.S0109中有详尽说明。7.2.3在Digest认证中使用GBA
如果客户端和服务器之间采用Digest认证（见IETFRFC2617），客户端和服务器应遵从3GPPTS33.220和3GPPTS24.109中所述的流程。7.2.4在HTTPS摘要认证下使用GBA如果客户端和服务器在Digest认证的HTTPS中使用GBA，客户端和服务器应遵从3GPPTS33.220和3GPPTS24.109中所述的流程。7.2.5GBA适用于PSK-TLS中
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。