手机电视(CMMB+MBBMS)安全架构原理

1      CMMB和MBBMS

1.1      定义

CMMB是ChinaMobile Multimedia Broadcasting (中国移动多媒体广播)的简称。是国内自主研发的第一套面向手机、笔记本电脑等多种移动终端的系统,利用S波段信号实现“天地”一体覆盖、全国漫游,支持25套电视和30套广播节目。2006年10月24日,国家广电总局正式颁布中国移动多媒体广播(俗称手机电视)行业标准,确定采用我国自主研发的移动多媒体广播行业标准。标准适用于30MHz到3000MHz频率范围内的广播业务频率,通过卫星和/或地面无线发射电视、广播、数据信息等多媒体信号的广播系统,可实现全国漫游。

MBBMS是指MobileBroadcast Business Management System (广播式手机电视业务管理系统),它的基础是利用现有移动通信网络的管理、计费系统和认证鉴权机制,实现对手机电视用户的管理。

CMMB是一个独立的系统,它可以脱离MBBMS独立的运行,但是无法使用MBBMS所带来的现有的移动通信网络资源。比如,MBBMS的密钥核心算法在SIM卡上存储和执行,CMMB CA的密钥核心算法在小卡/SMD/大卡上存储和执行。再比如,仅仅是CMMB无法使用移动网络现有的计费系统。

MBBMS提供了一系列使用现有移动资源的方法,除CMMB之外的其他手机电视标准也可以使用这些方法,比如MBMS。

1.2  工作原理

首先说硬件,需要提供一颗CMMB芯片,负责调频,接收数据,改芯片上还需要集成一块UAM芯片,负责一些核心解密算法的实现。如果是脱离MBBMS的单独的CMMB系统,还需要提供一块小卡,该小卡的功能类似于MBBMS中的UAM+SIM卡。另外,CMMB理论上使用30MHz~3000MHz频率范围。

CMMB的基本工作原理类似于收音机。也就是调到一定的频段,然后读取某个或某些时隙。物理层逻辑信道分为控制逻辑信道(CLCH)和业务逻辑信道(SLCH)。控制逻辑信道用于承载广播控制信息,业务逻辑信道用于承载广播业务。物理层只有一个固定的控制逻辑信道,占用系统的第0时隙发送。业务逻辑信道由系统配置,每个物理层带宽内业务逻辑信道的数目可以为1~39个,每个业务逻辑信道占用整数个时隙。

2      基础知识

鉴权(authentication)是指验证用户是否拥有访问系统的权利。传统的鉴权是通过密码来验证的。MBBMS采用对称密钥加密系统,即发送和接收数据的双方必使用相同的密钥对明文进行加密和解密运算。算法一般采用AES。

在进行网络交换数据时,一般采用HTTP Digest方法。

2.1      HTTP Digest

1.客户端希望取到服务器上的某个资源,向服务器发送Get请求。

2.服务器收到客户端的请求后,发现这个资源需要认证信息,判断请求报文中是否带有Authorization头,如果没有,返回一个 401(Unauthorized)给客户端。在这个401的回复中,同时服务器会加入一个WWW-Authenticate的头,其中有如下信息(各个字段的详细解释见RFC2617):

challenge        = "Digest" digest-challenge

digest-challenge  = 1#( realm | [ domain ] | nonce |

[ opaque ] |[ stale ]| [ algorithm ] |

[ qop-options ] |[auth-param] )

domain            = "domain" "="<"> URI ( 1*SP URI ) <">

URI               = absoluteURI | abs_path

nonce             = "nonce" "="nonce-value

nonce-value       = quoted-string

opaque            = "opaque" "="quoted-string

stale             = "stale" "="( "true" | "false" )

algorithm         = "algorithm" "="( "MD5" | "MD5-sess" |

token )

qop-options       = "qop" "="<"> 1#qop-value <">

qop-value         = "auth" |"auth-int" | token

3.客户端收到服务器的401(Unauthorized)回复后,使用服务器回复报文中的nonce值,加上 username,password,http method, http uri利用MD5(或者服务器指定的其他算法)计算出request-digest,作为repsonse头域的值。并重新发送请求,请求报文中包含 Authorization 头,其中有如下信息:

credentials      = "Digest" digest-response

digest-response  = 1#( username | realm | nonce | digest-uri

| response | [ algorithm] | [cnonce] |

[opaque] | [message-qop]|

[nonce-count]  | [auth-param] )

username         = "username" "="username-value

username-value   = quoted-string

digest-uri       = "uri" "="digest-uri-value

digest-uri-value = request-uri   ; As specified by HTTP/1.1

message-qop      = "qop" "=" qop-value

cnonce           = "cnonce" "="cnonce-value

cnonce-value     =nonce-value

nonce-count      = "nc" "=" nc-value

nc-value         = 8LHEX

response         = "response" "="request-digest

request-digest = <"> 32LHEX<">

LHEX             = "0" | "1" | "2" | "3" |

"4" | "5" |"6" | "7" |

"8" |"9" | "a" | "b" |

"c" |"d" | "e" | "f"

4.服务器收到客户端发来的请求后,根据username,查找出用户的password,用和客户端同样的方法计算出request- digest(response)。然后和收到的request-digest进行对比,如果一致,则验证成功,接受客户端的请求,成功返回结果。

2.2      AV3,5鉴权

3      加密流程

3.1      GBA

通用认证机制GBA(General Bootstrapping Architecture),是3GPP定义的一种利用现有移动通信网络资源的认证机制。最终的一个目的就是为了在终端与业务平台之间共享一个秘密的密钥,用于安全通信。 GBA流程中使用HTTP Digest,此协议的好处是无需明文传password,跟目前网站流行的加密密码是一个道理。明文传username,然后查询password并算出。所谓Digest,是因为采用了某些摘要算法,如MD5。另外,需要用到2G和3G的鉴权机制。

1.mbbmsExecuteGBA,通过SetRequest把REQ放入g_requestListHeader,然后通过GetRequest把REQ拿到g_currentRequest

此REQ的特征:

req.cmd= REQCMD_INITIALIZE;

req.param= force;

2.在REQ处理线程中,进入InnerInitialize

3.get imsi, HTTP_SendRequest(httpHandle, NULL, gbaBuf, STRLEN(gbaBuf), 0, 0, 0),其中有HTTP的header和gbaBuf

(HTTP的请求消息体,类似这样的消息

"<?xmlversion="1.0" encoding="UTF-8"?>

<UserID

xmlns:xs="http://www.w3.org/2001/XMLSchema\"xmlns="urn:3GPP:metadata:2005:mTV:IMPIRequest"

Type="IMSI"

TerminalCapability="%s"

UserAgent="%s">

%s

</UserID>",

其中UserID就是imsi)

4.然后函数进入循环死等RESP,成功后 解析Bootstrapping_Initiation.RESP

5.Create一个IMPI,impi:[email protected],通过uam_get_version来获取Version

6.Create一个Digest请求,继续死等RESP

7.开始鉴权ProcessGbaUnAuthorized,具体步骤是首先是SIM Card鉴权(2G,3G不同的鉴权步骤),然后是UAM鉴权。

卡鉴权做完之后(即AV3,5鉴权)利用鉴权的中间结果,进行UAM鉴权。发送给UAM的中间结果是:如果是SIM卡,在命令中携带(Kc,RAND,Ks-Input,SRES), 如果是USIM卡,在命令中携带(RES,CK,IK)。UAM计算Ks和RES‘,并生成cnonce,把Ks存储下来,并将RES‘和cnonce返回给终端。然后发送RES’给网络,网络生成Ks生命周期和B-TID,并发给终端。

8.网络生成Ks生命周期和B-TID,返回给终端,写入UAM中。

综上,GBA之后,终端和网络都生成了用户共享密钥Ks,这是以后所有密钥工作的基础。

3.2      获取MSK

MSK是通过HTTP交互获取的:根据订购关系表拿到MSKID,然后向网络发起请求

Fieldname Content-Type, value application/mbms-msk+xml

里面带有KeyDomainID和MSKID。

然后收到HTTP RESP,从中拿到 MSK Mikey。?

这是一个MSK Mikey的例子:

MSK:010015000C84B26D00010503000B00030100000104025A22E40B0250E7A1D9061031353730313439303936383836353833060000196E61662E6D62626D732E6368696E616D6F62696C652E636F6D010000355677744A2B62657733794B30487532535259494F74673D3D406273662E626A2E6D62626D732E6368696E616D6F62696C652E636F6D0001001E4534458CE203062C74A37816FCC3ABFAD4D3D39B58F5452BFFB4EB60CF7601041C2A6A570E7F3EE0F07494EDD3642714F61D75

拿到MSK Mikey后,通过UAM计算出MSK。

3.3      获取MTK

1.然后试图播放一个频道。如果是加密频道,需要解析SG里的SDP,拿到相关的解扰参数。这里是一个SDP的例子

<SDP>v=0o=- 1736101621 822899201 IN IP4 192.168.2.77 s=Profile 1 c=IN IP4 224.12.34.56/64t=0 0 a=min-buffer-time:1002 a=IPDCKSMStream:1 a=IPDCKSMStream:607a=IPDCKSMStream:607 m=video 55410 RTP/AVP 96 b=AS:356 b=TIAS:337792 b=RS:3000b=RR:0 a=rtpmap:96 enc-mpeg4-generic/90000
a=fmtp:96 profile-level-id=127;config=0142E00DFFE1000B6742E00D96520283F4900801000468CE3880; streamtype=4;ObjectType=33; mode=avc-video; DTSDeltaLength=22; RandomAccessIndication=1;ISMACrypCryptoSuite=AES_CTR_128; ISMACrypIVLength=4; ISMACrypDeltaIVLength=0;ISMACrypSelectiveEncryption=0;
ISMACrypKeyIndicatorLength=1;ISMACrypKeyIndicatorPerAU=1; ISMACrypSalt=base64,ubH5Rf/nCGI=a=cliprect:0,0,240,320 a=framerate:25. a=mpeg4-esid:201a=x-envivio-verid:0002302D a=mid:1 a=avg-br:355392 a=maxprate:55. m=audio 55412RTP/AVP 97 b=AS:42 b=TIAS:33831
b=RS:525 b=RR:0 a=rtpmap:97enc-mpeg4-generic/48000/2 a=fmtp:97 profile-level-id=15; config=131056E598;streamtype=5; ObjectType=64; mode=AAC-hbr; SizeLength=13; IndexLength=3;IndexDeltaLength=3; ISMACrypCryptoSuite=AES_CTR_128; ISMACrypIVLength=4;ISMACrypDeltaIVLength=0;
ISMACrypSelectiveEncryption=0;ISMACrypKeyIndicatorLength=1; ISMACrypKeyIndicatorPerAU=1;ISMACrypSalt=base64,ubH56f/nCGI= a=mpeg4-esid:101 a=x-envivio-verid:0002302Da=mid:2 a=avg-br:32000 a=maxprate:25.4375 m=data 7691 UDP ipdc-ksma=fmtp:ipdc-ksm IPDCStreamId=1;
IPDCKMSId=1; IPDCOperatorId=8 m=data 7491 UDPipdc-ksm a=fmtp:ipdc-ksm IPDCStreamId=607; IPDCKMSId=6176; IPDCOperatorId=3089m=data 7401 UDP ipdc-ksm a=fmtp:ipdc-ksm IPDCStreamId=607; IPDCKMSId=6178;IPDCOperatorId=3089</SDP>

其中

ISMACrypCryptoSuite=AES_CTR_128; ISMACrypIVLength=4;ISMACrypDeltaIVLength=0; ISMACrypSelectiveEncryption=0;ISMACrypKeyIndicatorLength=1; ISMACrypKeyIndicatorPerAU=1;ISMACrypSalt=base64

这些就是对加密进行描述的参数。

然后根据加扰相关参数信息从加密节目流中RTP包的AU头取出keyIndicator和IV。

根据协议AU Header的结构如下:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.. -+-+-+-+-+-+-+-+-+-+

|AU-headers-length|AU-header|AU-header|      |AU-header|padding|

|                 |   (1)  |   (2)   |     |   (n)   | bits |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.. -+-+-+-+-+-+-+-+-+-+

例子:

比如某数据流第一秒数据的第一个视频单元,原数据如下:

0,2a, f5, 85, 4d, fe, 6f, 0, fd, 63, b2, 2e, 70, 92, 70,e0….

其中0,2a是指的是AuHeader的长度(42bits ,换算成byte是6)所以真正的加密数据从fd,63… 开始。在AuHeader中ismaCrypIVLength为4,ismaCrypKeyIndicatorLength为1,所以KeyIndicator为6f,而IV为f5, 85, 4d,fe

然后,根据key Indicator从key Indicator和MTK(CW)的对应关系表中查找对应的MTK(CW)

输入Mikey到UAM,输出MTK。

3.4      解扰

然后就是解扰,使用MTK(CW)以及CW、IV、SDP中的Salt等信息,解密节目流。

比较常用的是AES解密方法。

4      总结

综上,整个MBBMS的安全架构已经比较清晰了,可以用下面这张图来概括一下:

时间: 2024-10-06 06:50:50

手机电视(CMMB+MBBMS)安全架构原理的相关文章

appium 架构原理

Appium是在手机操作系统自带的测试框架基础上 实现的,Android和ios的系统上使用 的工具是: Android(版本>4.2):UIAutomator,Android4.2之后系统自带 的UI自动化测试工具. IOS:UIAutomation,IOS系统自带的UI自动化测试工具. Appium的架构原理如图,由客户端和服务器两部分组成,客户端与服务器通过 JSON Wire协议进行通信: Appium 在Android上基于UIAutomator实现了测试代理程序(Bootstrap.

以属性为核心驱动的 全领域通用架构设计原理 (简称:属性架构原理)

以属性为核心驱动的全领域通用架构设计原理 (简称:属性架构原理) 联系方式:13547930387 Email:[email protected] 一.个人声明 我,参加工作也有5年多了,是一名普通的不能在普通的程序员,一直在使用公司自己的产品进行开发,因此技术比较菜,此设计完全是按照自己天真的想法而设计的,如果有不合理或很搞笑的地方,请轻拍,由衷的希望大家能提出宝贵的意见: 根据此设计原理我也做了一个简单的(demo)架构来支撑和验证此理论的可行性,由于技术功底不太好,有不合理之处请大家谅解,

【转】.NET/ASP.NET Routing路由(深入解析路由系统架构原理)

阅读目录: 1.开篇介绍 2.ASP.NET Routing 路由对象模型的位置 3.ASP.NET Routing 路由对象模型的入口 4.ASP.NET Routing 路由对象模型的内部结构 4.1]UrlRoutingModule 对象内部结构 4.2]RouteBase.Route.RouteCollection.RouteTable 路由核心对象模型 4.3]RouteValueDictionary.RouteData.RequestContext 路由数据对象模型 4.4]IRou

NET/ASP.NET Routing路由(深入解析路由系统架构原理)(转载)

NET/ASP.NET Routing路由(深入解析路由系统架构原理) 阅读目录: 1.开篇介绍 2.ASP.NET Routing 路由对象模型的位置 3.ASP.NET Routing 路由对象模型的入口 4.ASP.NET Routing 路由对象模型的内部结构 4.1UrlRoutingModule 对象内部结构 4.2RouteBase.Route.RouteCollection.RouteTable 路由核心对象模型 4.3RouteValueDictionary.RouteData

(2)LVS+Keepalived高可用负载均衡架构原理及配置

1.keepalived 介绍2.keepalived 优缺点3.keepalived 应用场景4.keepalived 安装配置5.keepalived+lvs 高可用6.keepalived+nginx 高可用7.keepalived 切换原理8.性能优化9.常见故障 一.keepalived 介绍 1.keepalived 定义keepalived是一个基于VRRP(virtual route redundent protocol)协议来实现的LVS服务高可用方案,可以利用其来避免单点故障

Kafka架构原理

对于kafka的架构原理我们先提出几个问题? 1.Kafka的topic和分区内部是如何存储的,有什么特点? 2.与传统的消息系统相比,Kafka的消费模型有什么优点? 3.Kafka如何实现分布式的数据存储与数据读取? Kafka架构图 1.kafka名词解释 在一套kafka架构中有多个Producer,多个Broker,多个Consumer,每个Producer可以对应多个Topic,每个Consumer只能对应一个ConsumerGroup. 整个Kafka架构对应一个ZK集群,通过ZK

Hive的配置| 架构原理

Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张表,并提供类SQL查询功能. 本质是:将HQL转化成MapReduce程序 1)Hive处理的数据存储在HDFS 2)Hive分析数据底层的实现是MapReduce 3)执行程序运行在Yarn上 Hive架构原理 Hive安装及配置 (1)把apache-hive-1.2.1-bin.tar.gz上传到linux的/opt/software目录下 (2)解压apache-hive-1.2.1-bin.tar.gz到/o

EasyScheduler调度系统的架构原理及实现思路

系统架构设计 在对调度系统架构说明之前,我们先来认识一下调度系统常用的名词 1.名词解释 DAG: 全称Directed Acyclic Graph,简称DAG.工作流中的Task任务以有向无环图的形式组装起来,从入度为零的节点进行拓扑遍历,直到无后继节点为止.举例如下图: 流程定义:通过拖拽任务节点并建立任务节点的关联所形成的可视化DAG 流程实例:流程实例是流程定义的实例化,可以通过手动启动或定时调度生成 任务实例:任务实例是流程定义中任务节点的实例化,标识着具体的任务执行状态 任务类型:

RocketMQ(1)-架构原理

RocketMQ(1)-架构原理 RocketMQ是阿里开源的分布式消息中间件,跟其它中间件相比,RocketMQ的特点是纯JAVA实现:集群和HA实现相对简单:在发生宕机和其它故障时消息丢失率更低. 一.RocketMQ专业术语 先讲专业术语的含义,后面会画流程图来更好的去理解它们. Producer 消息生产者,位于用户的进程内,Producer通过NameServer获取所有Broker的路由信息,根据负载均衡策略选择将消息发到哪个Broker,然后调用Broker接口提交消息. Prod