WO2011020332A1 - 一种ip多媒体子系统会议媒体数据的加密方法及系统 - Google Patents
一种ip多媒体子系统会议媒体数据的加密方法及系统 Download PDFInfo
- Publication number
- WO2011020332A1 WO2011020332A1 PCT/CN2010/071831 CN2010071831W WO2011020332A1 WO 2011020332 A1 WO2011020332 A1 WO 2011020332A1 CN 2010071831 W CN2010071831 W CN 2010071831W WO 2011020332 A1 WO2011020332 A1 WO 2011020332A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- media data
- terminal
- information
- encryption
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
- H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
Definitions
- the present invention relates to an IP Multimedia System (IMS) in the field of mobile communications, and more particularly to an encryption method and system for IMS conference media data.
- IMS IP Multimedia System
- IP Multimedia Subsystem is a new form of multimedia service that meets the needs of end users for new and diverse multimedia services.
- IMS IP Multimedia Subsystem
- IMS is considered to be the core technology of the next generation network, and it is also an important way to solve the convergence of mobile and fixed networks and introduce differentiated services such as voice, data and video triple integration.
- IMS-based conferencing provides users with the ability to create, manage, terminate, join, and leave a meeting, and also provides users with the ability to query participating user information.
- users can communicate using any type of media stream, such as: audio, video, whiteboard, instant messaging, image files, games, and more.
- the IMS conference is a centralized conference and requires the IMS core network to provide application server support, such as:
- the service-type call session control function (S-CSCF) provided by the IMS core network is used for session initiation protocol (SIP) negotiation in the conference service, IMS.
- SIP session initiation protocol
- MRFC Media Resource Control Function
- MRFP Media Resource Processing Function
- the conference policy server provided by the IMS core network is used to manage the loading user and The conference strategy developed by the operator.
- IMS can be deployed on a variety of networks, such as: third-generation digital communication (3G) networks, second-generation digital communication (2G) networks, wireless local area networks (WLANs), and the Internet.
- 3G third-generation digital communication
- 2G second-generation digital communication
- WLANs wireless local area networks
- the Internet the Internet.
- the main object of the present invention is to provide an encryption method and system for IMS conference media data, which can easily encrypt media data of an IMS conference.
- the present invention discloses an encryption method for IMS conference media data, the method comprising: the terminal notifying the server of its own cipher suite information, and the server selecting a cipher suite to be used from the received cipher suite information;
- the terminal applies for the floor and notifies the server of the encryption key corresponding to the cipher suite selected by the server, and the terminal transmits the encrypted media data to the server after the server's speech allows.
- the method further includes: the server determining whether the participant has the media data encryption capability, and if yes, transmitting the encrypted media data to the participant member terminal; , the encrypted media data is decrypted and sent to the participant member terminal.
- the method further includes: adding, by the terminal, media data encryption capability information to the session description protocol (SDP) information, and performing SDP negotiation with the server;
- SDP session description protocol
- the server determines whether the participant has the media data encryption capability as: determining whether the participant member terminal adds the media data encryption capability information to the SDP information, and if added, the media data encryption capability, if not added , does not have the ability to encrypt media data.
- the terminal adds media data encryption capability information to the SDP information, and performs SDP negotiation between servers, specifically:
- the terminal sends the SDP information of the media data encryption capability information to the server, and the server notifies the terminal after receiving the message;
- the server notifies the terminal of the media codec set of the conference and the deterministic information with the encryption function
- the terminal and the server perform respective resource reservation operations
- the terminal updates its own media description information and notifies the server, the server determines the media type of the conference, and determines whether to perform media data encryption;
- the terminal and the server confirm that the SDP negotiation is completed.
- the terminal notifies the server of its own cipher suite information, specifically: the terminal establishes a secure transport layer protocol (TLS) connection with the server, and then the terminal notifies the server of its cipher suite information through a floor control protocol (BFCP).
- TLS secure transport layer protocol
- BFCP floor control protocol
- the cipher suite information is: 3DES in the Data Encryption Standard (DES), or an Advanced Encryption Standard (AES) symmetric encryption algorithm;
- the cipher suite information is included in the BFCP extension attribute CIPHER_SUITE_INF 0;
- the encryption key is included in the message extension attribute KEY_DATA_INFO of the BFCP.
- the present invention also discloses an encryption system for IMS conference media data, the system comprising: a terminal and a server;
- the terminal is configured to notify the server of its own cipher suite information; apply for a floor, and notify the server of the encryption key corresponding to the cipher suite selected by the server, and send the encrypted media data to the server after the server's utterance permits. ;
- the server is configured to select a ciphering suite to be used from the cipher suite information sent by the terminal, and receive the cryptographic key uploaded by the terminal and the encrypted media data.
- the server is further configured to determine whether the participant has media data encryption. Capability, if the participant has the media data encryption capability, the encrypted media data is sent to the participant member terminal; if the participant member does not have the media data encryption capability, the encrypted media data is decrypted and sent to the participant member terminal. ; corresponding,
- the system further includes a participant member terminal, configured to receive encrypted media data delivered by the server, or receive media data decrypted by the server and sent by the server.
- the terminal is further configured to add media data encryption capability information to the SDP information, and perform SDP negotiation with the server;
- the server is further configured to perform SDP negotiation with the terminal.
- the terminal adds media data encryption capability information to the SDP information, and performs SDP negotiation with the server, specifically:
- the server performs SDP negotiation with the terminal, specifically:
- the IMS conference media data encryption method and system provided by the present invention, the terminal notifies the server of its own cipher suite information, and the server selects a cipher suite to be used from the received cipher suite information; the terminal applies for a floor, and the server The encryption key corresponding to the encryption kit is selected to notify the server, and the terminal transmits the encrypted media data to the server after the server's speech allows.
- the invention can realize the encryption of the media data of the IMS conference, and ensures the confidential transmission of the media data.
- the invention completes the selection operation of the cipher suite by using the Hello message and the Hello Ack message in the BFCP unique to the IMS conference, and transmits the key data by using the FloorRequest message in the BFCP.
- the method of implementation is simple.
- FIG. 1 is a schematic flowchart of an implementation method of an encryption method of an IMS conference media data according to the present invention
- FIG. 2 is a schematic diagram showing the structure of a BFCP extension attribute CIPHER-SUITE-INFO according to the present invention
- FIG. 3 is a schematic structural diagram of an extended attribute KEY_DATA_INFO of a BFCP according to the present invention
- FIG. 4 is a schematic flowchart of SDP negotiation between a terminal and a server according to the present invention
- FIG. 5 is a schematic structural diagram of an encryption system of an IMS conference media data according to the present invention. detailed description
- the transmission of media data is negotiated via SIP.
- the terminal needs to add the type, codec, and media attribute information of the media data supported by the terminal to the SDP information, and notify the server through the Invite message in the SIP, and the server selects a media combination suitable for the current session according to its own media capability.
- the current session, and the terminal is notified of the selected media combination by a response message carrying a 200 OK.
- the terminal notifies the server of its own cipher suite information, the server selects a cipher suite to be used from the received cipher suite information; the terminal applies for a floor, and encrypts the encryption corresponding to the cipher suite selected by the server.
- the key informs the server that the terminal transmits the encrypted media data to the server after the server's speech allows.
- the terminal is an originating terminal of an IMS conference
- the server is a server provided by an IMS core network.
- FIG. 1 is a schematic flowchart of an encryption method of an IMS conference media data according to the present invention. As shown in FIG. 1, the process includes the following steps:
- Step 101 The terminal adds media data encryption capability information to the SDP information, and performs SDP negotiation with the server.
- Step 102 The terminal establishes a TLS connection with the server.
- TLS Transmission Control Protocol
- Step 103 The terminal notifies the server of the cipher suite information through the BFCP; specifically, the terminal sends the BFCP Hello message to the server through the BFCP, and the BFCP Hello message carries the cipher suite information.
- the cipher suite information is a symmetric encryption algorithm such as 3DES or Advanced Encryption Standard (AES) in the Data Encryption Standard (DES); the symmetric encryption algorithm is included in the newly added BFCP extension attribute CIPHER of the present invention.
- – SUITE—In INFO the extended attribute CIPHER— SUIT E— INFO is included in the BFCP Hello message.
- Figure 2 is a schematic diagram of the structure of the BFCP extension attribute CIPHE R-SUITE_INFO. As shown in Figure 2, the first seven bits of CIPHER_SUITE_INFO are the type values of the extended attributes, which are expressed in hexadecimal as 0x13. The eighth bit is the mandatory indicator bit, indicating whether this attribute is mandatory.
- CIPHER_SUITE_INFO After the mandatory indication bit is the length value of CIPHER_SUITE_INFO, the length is eight bits, and the value is 0x03.
- the message extension attribute of the BFCP is obtained by coding and spreading the message attribute value (TLV) of the BFCP.
- Step 104 The server selects a ciphering suite to be used from the received cipher suite information. Specifically, the server selects, according to its own media capability, a symmetric cipher for encrypting the media data from the cipher suite information reported by the terminal. Algorithm, and pass BFCP
- the HelloAck message is sent to the terminal to confirm the BFCP Hello message sent by the terminal, and only one of the attribute values of the CIPHER_SUITE_INFO attribute in the BFCP HelloAck message is set to 1.
- Step 105 The terminal applies for the floor, and notifies the server of the encryption key corresponding to the cipher suite selected by the server;
- the terminal applies for the floor and sends a BFCP FloorRequest message to the server.
- the extended attribute KEY_DATA_INFO in the message carries the encryption key used by the terminal to encrypt the media data.
- the encryption key is included in the BFCP extended attribute KEY_DATA_INFO of the newly added BFCP of the present invention, and the extended attribute KEY_DATA_INFO is included in the BFCP FloorRequest message.
- Figure 3 is a schematic diagram of the structure of the extended attribute KEY_DATA_INFO of the BFCP. As shown in Figure 3, the first seven bits of the KEY_DATA_INFO are the type values of the extended attribute, and the hexadecimal representation is 0x14. The eight bits are mandatory indicators, indicating whether the attribute is mandatory. The mandatory indicator bit is followed by an eight-bit key length value. If the symmetric encryption algorithm selected by the server is 3DES, the key length may be 128 bits or 192 bits.
- the key length can be 128 bits, 192 bits, or 256 bits.
- the attribute value of KEY_DATA_INFO can be 16 bytes, 24 bytes, or 32 bytes of data. If the total length of the KEY_DATA_INFO attribute is not 32 bytes aligned, it must be padded.
- Step 106 The terminal sends the encrypted media data to the server after allowing the server to speak;
- the server sends a BFCP FloorRequestStatus message to the terminal, and notifies the terminal that the terminal can speak. After receiving the message that the permission is allowed to be sent, the terminal sends the encrypted media data to the service.
- the media data is encrypted by the encryption key specified in the selected BFCP HelloAck message.
- the step further includes: if the server does not allow the terminal to speak, the terminal does not send the media data to the server.
- the server further includes: after receiving the encrypted media data, the server determines, according to the media data encryption capability information uploaded by the member, whether the participant has the media data encryption capability, and if yes, sends the encrypted media data. To the participant terminal, if it is not available, the encrypted media data is decrypted and sent to the participant member terminal.
- the participant having the media data encryption capability obtains the encryption key of the received media data through the FloorStatus message sent by the server.
- Step 101 The terminal adds the media data encryption capability information to the SDP information, and performs the SDP negotiation process with the server. As shown in FIG. 4, the method includes the following steps:
- Step 401 The terminal sends the SDP information that adds the media data encryption capability information to the server.
- the terminal describes the media capability information, the network bandwidth information required for the media data, and the media data encryption capability information by using the SDP, and adds the information to the SIP Invite message to the server, where the SIP Invite message header is Require.
- the field contains preconditaion, indicating that the terminal supports reliable temporary message response and resource reservation capabilities.
- the method for describing the media data encryption capability information is: adding a new media attribute p r i vaC y in the media data described by the SDP, and when the terminal has the media data encryption capability, the value is 1; When the terminal does not have the media data encryption capability, the value is 0.
- the terminal in order to be compatible with the transmission of the traditional media data, when there is no media attribute privacy in the SDP information of the media, the terminal is considered to have no media data encryption capability.
- Step 402 The server notifies the terminal after receiving the SDP information.
- the server sends a 100 Trying message to the terminal after receiving the SIP Invite message, and notifies the terminal server that the SIP Invite message has been received, so that the terminal does not need to send the SIP Invite again. Message.
- Step 403 The server notifies the terminal of the media codec set of the conference and the determining information with the encryption function.
- the server selects the media codec set of the conference, and indicates that the server has the media data encryption capability in the media attribute privacy described by the SDP, and the media codec set and the server have the media data encryption capability information. 183 Session Progress Send to the terminal.
- Step 404 The terminal and the server perform respective resource reservation operations.
- the terminal and the server start the process of reserving the media bandwidth resource, and after the terminal and the server bearer establish a corresponding resource reservation, send a SIP PRACK message to the server, indicating that the terminal has completed the resource reservation operation, and the server completes the media.
- the response message carrying the 200 OK is sent to the terminal to respond to the SIP PRACK message, and the terminal server is notified that the resource reservation operation has also been completed.
- Step 405 The terminal updates its own media description information according to the received media codec set and notifies the server.
- the terminal updates its media description information according to the media codec set sent by the server, and sends the updated media description information to the server by using a SIP UPDATE message.
- the update information may be network bandwidth information or the like; and the updated information still includes media data encryption capability information.
- Step 406 The server determines the media type of the conference, and determines whether to perform media data encryption. Specifically, the server sends a response message carrying the 200 OK to the terminal in response to the SIP UPDATE message, and specifies the media of the conference in the SDP of the SIP UPDATE message. Type and whether to encrypt media data.
- Step 407 The terminal and the server confirm that the SDP negotiation is completed.
- the server sends a response message carrying a 200 OK to the terminal, to initially send the terminal
- the sent SIP Invite message responds, and the terminal receives the response message carrying the 200 OK and then returns an ACK message to the server.
- the media data transmission can be started.
- FIG. 5 is a schematic structural diagram of an encryption system of an IMS conference media data according to the present invention. As shown in FIG. 5, the system includes: a terminal and a server;
- the terminal is configured to notify the server of its own cipher suite information; apply for a floor, and notify the server of the encryption key corresponding to the cipher suite selected by the server, and send the encrypted media data to the server after the server's utterance permits. ;
- the server is configured to select a ciphering suite to be used from the cipher suite information sent by the terminal, and receive the cryptographic key uploaded by the terminal and the encrypted media data.
- the terminal is further configured to add media data encryption capability information to the SDP information, and perform SDP negotiation with the server;
- the server is further configured to perform SDP negotiation with the terminal.
- the terminal adds media data encryption capability information to the SDP information, and performs SDP negotiation with the server, specifically:
- the server is further configured to determine whether the participating member has the media data encryption capability, and if the participating member has the media data encryption capability, the encrypted media data is sent to the participant member terminal; determining that the participating member does not have the media data encryption Ability to solve encrypted media data After the secret is sent to the member terminal; correspondingly,
- the system further includes a participant member terminal, configured to receive encrypted media data delivered by the server, or receive media data decrypted by the server and sent by the server.
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
一种 IP多媒体子系统会议媒体数据的加密方法及系统
技术领域
本发明涉及移动通信领域中的 IP多媒体系统( IMS ),尤其涉及一种 IMS 会议媒体数据的加密方法及系统。 背景技术
IP多媒体系统 ( IP Multimedia Subsystem, IMS )是一种全新的多媒体 业务形式, 能满足终端用户新颖、 多样化的多媒体业务需求。 目前, IMS 被认为是下一代网络的核心技术, 也是解决移动与固网融合, 引入语音、 数据、 视频三重融合等差异化业务的重要方式。
基于 IMS的会议可向用户提供创建、 管理、 终止、 加入和离开会议的 功能, 还向用户提供查询参会用户信息的功能。 在 IMS会议中, 用户可使 用任意类型的媒体流进行通信, 如: 音频、 视频、 白板、 即时消息、 图像 文件、 游戏等等。 IMS会议是集中型会议, 需要 IMS核心网提供应用服务 器支持, 如: IMS核心网提供的业务型呼叫会话控制功能(S-CSCF ) 实体 用于会议业务中会话初始化协议(SIP ) 的协商, IMS核心网提供的媒体资 源控制功能(MRFC ) 实体和媒体资源处理功能(MRFP ) 实体用于处理各 种媒体流的处理和切换以及发言权, IMS核心网提供的会议策略服务器用 于管理加载用户和运营商制订的会议策略。
IMS可以部署于多种网络, 如: 第三代数字通信(3G ) 网、 第二代数 字通信(2G ) 网、 无线局域网 (WLAN )和互联网等, 由于不同网络的安 全差异较大, 因此, 当大规划部署 IMS业务时需要考虑媒体传输的安全性 问题, 当然, IMS会议业务也需要考虑到该安全性问题。 目前, 关于 IMS 业务的安全性问题提出的解决方案是网络安全性协议(IPSec ), 但是 IPSec
还处于互联网协议的第四版 IPv4阶段, IPSec作为 IPv4的可选补充, 还没 有得到广泛部署, 因此 IPSec不适用于 IMS会议业务。 此外, 可以考虑使 用安全实时传输协议( SRTP )解决 IMS会议业务中媒体传输的安全性问题, 但这可能涉及到公钥基础设施, 因此实施方法繁瑣, 目前很少有应用程序 釆用这个协议。 发明内容
有鉴于此, 本发明的主要目的在于提供一种 IMS会议媒体数据的加密 方法及系统, 可简便地实现对 IMS会议的媒体数据进行加密。
为达到上述目的, 本发明的技术方案是这样实现的:
本发明公开了一种 IMS会议媒体数据的加密方法, 该方法包括: 终端向服务器通知自身的加密套件信息, 服务器从收到的加密套件信 息中选择待用的加密套件;
终端申请发言权, 并将与服务器所选加密套件对应的加密密钥通知服 务器, 终端经服务器的发言允许后将经过加密的媒体数据发送到服务器。
其中, 所述终端将经过加密的媒体数据发送到服务器后, 进一步包括: 服务器判断参会成员是否具备媒体数据加密能力, 若具备, 则将加密 的媒体数据发送到参会成员终端; 若不具备, 则将加密的媒体数据解密后 发送到参会成员终端。
其中, 所述终端向服务器通知自身的加密套件信息之前, 还包括: 终 端在会话描述协议( SDP )信息中添加媒体数据加密能力信息, 并执行与服 务器间的 SDP协商;
相应的, 所述服务器判断参会成员是否具备媒体数据加密能力为: 判 断参会成员终端是否将媒体数据加密能力信息添加在 SDP信息中, 若已添 加, 则具备媒体数据加密能力, 若未添加, 则不具备媒体数据加密能力。
其中, 所述终端在 SDP信息中添加媒体数据加密能力信息, 并执行与
服务器间的 SDP协商, 具体为:
终端将添加媒体数据加密能力信息的 SDP信息发送到服务器, 服务器 收到后通知终端;
服务器将会议的媒体编解码集合及具备加密功能的确定信息通知终 端;
终端与服务器进行各自的资源预留操作;
终端更新自身的媒体描述信息并通知服务器, 服务器确定会议的媒体 类型, 并确定是否进行媒体数据加密;
终端与服务器确认 SDP协商完毕。
上述方案中, 所述终端向服务器通知自身的加密套件信息, 具体为: 终端与服务器建立安全传输层协议(TLS )连接, 之后终端通过发言权 控制协议(BFCP ) 向服务器通知自身的加密套件信息。
上述方案中, 所述加密套件信息为: 数据加密标准(DES )中的 3DES、 或高级加密标准 (AES )对称加密算法;
所述加密套件信息包含于 BFCP的 4艮文扩展属性 CIPHER— SUITE— INF 0中;
所述加密密钥包含于 BFCP的报文扩展属性 KEY— DATA— INFO中。 本发明还公开了一种 IMS会议媒体数据的加密系统, 该系统包括: 终 端和服务器; 其中,
所述终端, 用于向服务器通知自身的加密套件信息; 申请发言权, 并 将与服务器所选加密套件对应的加密密钥通知服务器, 经服务器的发言允 许后将经过加密的媒体数据发送到服务器;
所述服务器, 用于从终端发送的加密套件信息中选择待用的加密套件; 接收终端上传的加密密钥及经过加密的媒体数据。
其中, 所述服务器, 进一步用于判断参会成员是否具备媒体数据加密
能力, 确定参会成员具备媒体数据加密能力, 则将加密的媒体数据发送到 参会成员终端; 确定参会成员不具备媒体数据加密能力, 则将加密的媒体 数据解密后发送到参会成员终端; 相应的,
该系统进一步包括参会成员终端, 用于接收服务器下发的加密的媒体 数据, 或接收服务器下发的经服务器解密的媒体数据。
其中,所述终端进一步用于在 SDP信息中添加媒体数据加密能力信息, 并执行与服务器间的 SDP协商;
相应的, 所述服务器, 进一步用于执行与终端间的 SDP协商。
上述方案中, 所述终端在 SDP信息中添加媒体数据加密能力信息, 并 执行与服务器间的 SDP协商, 具体为:
将添加媒体数据加密能力信息的 SDP信息发送到服务器, 接收服务器 发送的会议的媒体编解码集合及服务器具备加密功能的确定信息, 进行资 源预留操作; 更新自身的媒体描述信息并通知服务器,确认 SDP协商完毕; 相应的, 所述服务器执行与终端间的 SDP协商, 具体为:
接收终端所发的添加媒体数据加密能力信息的 SDP信息, 并通知终端 已接收到添加媒体数据加密能力信息的 SDP信息; 将会议的媒体编解码集 合及具备加密功能的确定信息通知终端, 进行资源预留操作; 接收终端更 新的媒体描述信息, 确定会议的媒体类型, 并确定是否进行媒体数据加密。
本发明提供的 IMS会议媒体数据的加密方法及系统, 终端向服务器通 知自身的加密套件信息, 服务器从收到的加密套件信息中选择待用的加密 套件; 终端申请发言权, 并将与服务器所选加密套件对应的加密密钥通知 服务器, 终端经服务器的发言允许后将经过加密的媒体数据发送到服务器。 本发明可实现对 IMS会议的媒体数据进行加密, 确保了媒体数据的保密性 传输。 本发明利用 IMS会议特有的 BFCP中的 Hello消息和 Hello Ack消息 完成加密套件的选择操作,利用 BFCP中的 FloorRequest消息传送密钥数据,
实施方法简便。 附图说明
图 1为本发明 IMS会议媒体数据的加密方法实现流程示意图; 图 2为本发明 BFCP的 4艮文扩展属性 CIPHER— SUITE— INFO的结构示 意图;
图 3为本发明 BFCP的 4艮文扩展属性 KEY— DATA— INFO的结构示意图; 图 4为本发明终端与服务器进行 SDP协商的流程示意图;
图 5为本发明 IMS会议媒体数据的加密系统结构示意图。 具体实施方式
从现有技术可知, 对于 IMS会议, 媒体数据的传输需要会话描述协议 ( SDP )进行媒体类型、媒体带宽和媒体编解码的协商,媒体数据的传输许 可需要通过发言权控制协议( Binary Floor Control Protocol, BFCP )向服务 器进行申请, 只有服务器准许发送, 才能进行媒体数据的传输。
在 IMS会议中, 媒体数据的传输通过 SIP进行协商。 终端需要将自身 支持的媒体数据的类型、 编解码、 媒体属性信息等添加到 SDP信息中, 通 过 SIP中的 Invite消息通知服务器,服务器根据自身的媒体能力选择一种适 合当前会话的媒体组合用于当前会话,并通过携带 200 OK的响应消息将已 选择的媒体组合通知终端。
本发明的基本思想是: 终端向服务器通知自身的加密套件信息, 服务 器从收到的加密套件信息中选择待用的加密套件; 终端申请发言权, 并将 与服务器所选加密套件对应的加密密钥通知服务器, 终端经服务器的发言 允许后将经过加密的媒体数据发送到服务器。
这里, 所述终端为 IMS会议的发起终端, 所述服务器为 IMS核心网提 供的服务器。
下面结合附图及具体实施例对本发明作进一步详细说明。
图 1为本发明 IMS会议媒体数据的加密方法实现流程示意图, 如图 1 所示, 该流程包括以下步骤:
步骤 101 : 终端在 SDP信息中添加媒体数据加密能力信息, 并执行与 服务器间的 SDP协商;
步骤 102: 终端与服务器建立 TLS连接;
这里, 由于 BFCP釆用传输控制协议 ( TCP )进行数据传输, 因此釆用 TLS来提供保密性和数据完整性。
步骤 103: 终端通过 BFCP向服务器通知自身的加密套件信息; 具体为:终端通过 BFCP将 BFCP Hello消息发送到服务器, BFCP Hello 消息中携带加密套件信息。
这里, 所述加密套件信息为数据加密标准(DES ) 中的 3DES、 或高级 加密标准( AES )等对称加密算法; 所述对称加密算法包含于本发明新增的 BFCP的才艮文扩展属性 CIPHER— SUITE— INFO中, 扩展属性 CIPHER— SUIT E— INFO包含于 BFCP Hello消息中。 图 2为 BFCP的才艮文扩展属性 CIPHE R— SUITE— INFO的结构示意图, 如图 2所示, CIPHER— SUITE— INFO的前 七位是扩展属性的类型值, 用十六进制表示为 0x13 , 第八位是强制指示位, 表示本属性是否为必须, 在强制指示位之后是 CIPHER— SUITE— INFO的长 度值, 长度为八位, 取值为 0x03。 CIPHER— SUITE— INFO的属性值为八位, 只使用前两位, 分别用于表示是否支持 3DES对称加密算法和是否支持 AE S对称加密算法, 如果支持上述某种对称加密算法, 则相应的标志位置 1 , 其它位保留备用。 BFCP的报文属性必须是三十二字节对齐, 因此还需要八 字节填补。
本发明中,所述 BFCP的报文扩展属性是通过对 BFCP的报文属性釆用 类型长度值(TLV )进行编码扩展所得。
步骤 104: 服务器从收到的加密套件信息中选择待用的加密套件; 具体为: 服务器根据自身的媒体能力从终端上报的加密套件信息中选 择一种用于后续对媒体数据进行加密的对称加密算法, 并通过 BFCP
HelloAck消息发送到终端, 以对终端所发的 BFCP Hello消息进行确认, 所 述 BFCP HelloAck消息中 CIPHER— SUITE— INFO的属性值中只有一种对称 加密算法的对应标志位被置 1。
步骤 105: 终端申请发言权, 将与服务器所选加密套件对应的加密密钥 通知服务器;
具体为: 终端申请发言权, 将 BFCP FloorRequest消息发送到服务器, 消息中的扩展属性 KEY— DATA— INFO携带终端对媒体数据进行加密的加密 密钥。
这里,所述加密密钥包含于本发明新增的 BFCP的 艮文扩展属性 KEY— DATA— INFO 中, 扩展属性 KEY— DATA— INFO 包含于 BFCP FloorRequest 消息中。 图 3为 BFCP的 4艮文扩展属性 KEY— DATA— INFO的结构示意图, 如图 3所示, KEY— DATA— INFO的前七位是扩展属性的类型值, 十六进制 表示为 0x14, 第八位是强制指示位, 表示本属性是否为必须, 强制指示位 之后是八位的密钥长度值, 如果服务器选择的对称加密算法为 3DES, 则密 钥长度可以为 128位、 或 192位; 如果服务器选择的对称加密算法为 AES, 则密钥长度可以为 128位、 192位、 或 256位。 KEY— DATA— INFO的属性 值可以是 16字节、 24字节、 或 32字节的数据, 如果 KEY— DATA— INFO的 属性总长度非 32字节对齐, 那么必须进行填补。
步骤 106:终端经服务器的发言允许后将经过加密的媒体数据发送到服 务器;
具体为: 服务器将 BFCP FloorRequestStatus消息发送给终端, 通知终 端可以发言, 终端收到准许发言的消息后, 将加密的媒体数据发送到服务
器, 选用的 BFCP HelloAck消息中指定的加密密钥对媒体数据进行加密。 本步骤进一步包括: 若服务器不允许终端发言, 则终端不向服务器发 送媒体数据。
本发明步骤 106之后进一步包括: 服务器收到加密的媒体数据后, 根 据参会成员上传的媒体数据加密能力信息判断参会成员是否具备媒体数据 加密能力, 如果具备的, 则将加密的媒体数据发送到参会成员终端, 如果 不具备的, 则将加密的媒体数据解密后发送到参会成员终端。 这里, 所述 具备媒体数据加密能力参会成员通过服务器所发的 FloorStatus消息获得所 接受媒体数据的加密密钥。
步骤 101所述终端在 SDP信息中添加媒体数据加密能力信息, 并执行 与服务器间的 SDP协商的流程具体如图 4所示, 包括以下步骤:
步骤 401 : 终端将添加媒体数据加密能力信息的 SDP信息发送到服务 器;
具体为: 终端将自身支持的媒体能力信息、 媒体数据所需网络带宽信 息和媒体数据加密能力信息通过 SDP进行描述,并添加到 SIP Invite消息中 发送到服务器,所述 SIP Invite消息头部的 Require字段中包含 preconditaion, 表明终端支持可靠临时消息应答和资源预留能力。
本发明中, 所述媒体数据加密能力信息的描述方法为: 在通过 SDP描 述的媒体数据中增加新的媒体属性 privaCy, 当终端具备媒体数据加密能力 时, 取值为 1 ; 当终端不具备媒体数据加密能力时, 取值为 0。 这里, 为了 兼容传统的媒体数据的传输, 当媒体的 SDP信息中没有媒体属性 privacy 时, 认为终端不具备媒体数据加密能力。
步骤 402: 服务器收到 SDP信息后通知终端;
具体为: 服务器收到 SIP Invite消息后向终端发送 100 Trying消息, 通 知终端服务器已收到 SIP Invite消息, 这样, 终端则不需再次发送 SIP Invite
消息。
步骤 403:服务器将本次会议的媒体编解码集合及具备加密功能的确定 信息通知终端;
具体为: 服务器选择本次会议的媒体编解码集合, 并在 SDP描述的媒 体属性 privacy中指示服务器具备媒体数据加密能力, 并将媒体编解码集合 和服务器具备媒体数据加密能力的信息通过 183 Session Progress发送到终 端。
步骤 404: 终端与服务器进行各自的资源预留操作;
具体为: 终端与服务器开始进行媒体带宽资源的预留过程, 为: 终端 与服务器承载建立相应的资源预留后, 向服务器发送 SIP PRACK消息, 表 明终端已经完成资源预留操作, 服务器完成与媒体带宽资源对应的资源预 留操作后, 向终端发送携带 200 OK的响应消息对 SIP PRACK消息进行相 应, 通知终端服务器也已完成资源预留操作。
步骤 405:终端根据收到的媒体编解码集合更新自身的媒体描述信息并 通知服务器;
具体为: 终端根据服务器发送的媒体编解码集合更新自身的媒体描述 信息, 并将更新的媒体描述信息通过 SIP UPDATE消息发送到服务器。 这 里, 所述的更新信息可为网络带宽信息等; 所述已更新的信息中仍包括媒 体数据加密能力信息。
步骤 406:服务器确定会议的媒体类型,并确定是否进行媒体数据加密; 具体为: 服务器发送携带 200 OK 的响应消息到终端以回应 SIP UPDATE消息, 在 SIP UPDATE消息的 SDP中指定本次会议的媒体类型和 是否进行媒体数据加密。
步骤 407: 终端与服务器确认 SDP协商完毕;
具体为: 服务器发送携带 200 OK的响应消息到终端, 以对终端最初发
送的 SIP Invite消息进行响应, 终端收到携带 200 OK的响应消息后回复 ACK消息给服务器, SDP协商完毕, 可以开始进行媒体数据传输。
图 5为本发明 IMS会议媒体数据的加密系统结构示意图,如图 5所示, 该系统包括: 终端和服务器; 其中,
所述终端, 用于向服务器通知自身的加密套件信息; 申请发言权, 并 将与服务器所选加密套件对应的加密密钥通知服务器, 经服务器的发言允 许后将经过加密的媒体数据发送到服务器;
所述服务器, 用于从终端发送的加密套件信息中选择待用的加密套件; 接收终端上传的加密密钥及经过加密的媒体数据。
所述终端进一步用于在 SDP信息中添加媒体数据加密能力信息, 并执 行与服务器间的 SDP协商;
相应的, 所述服务器, 进一步用于执行与终端间的 SDP协商。
这里, 所述终端在 SDP信息中添加媒体数据加密能力信息, 并执行与 服务器间的 SDP协商, 具体为:
将添加媒体数据加密能力信息的 SDP信息发送到服务器, 接收服务器 发送的会议的媒体编解码集合及服务器具备加密功能的确定信息, 进行资 源预留操作; 更新自身的媒体描述信息并通知服务器,确认 SDP协商完毕; 所述服务器执行与终端间的 SDP协商, 具体为:
接收终端所发的添加媒体数据加密能力信息的 SDP信息, 并通知终端 已接收到添加媒体数据加密能力信息的 SDP信息; 将会议的媒体编解码集 合及具备加密功能的确定信息通知终端, 进行资源预留操作; 接收终端更 新的媒体描述信息, 确定会议的媒体类型, 并确定是否进行媒体数据加密。
所述服务器, 进一步用于判断参会成员是否具备媒体数据加密能力, 确定参会成员具备媒体数据加密能力, 则将加密的媒体数据发送到参会成 员终端; 确定参会成员不具备媒体数据加密能力, 则将加密的媒体数据解
密后发送到参会成员终端; 相应的,
该系统进一步包括参会成员终端, 用于接收服务器下发的加密的媒体 数据, 或接收服务器下发的经服务器解密的媒体数据。
以上所述, 仅为本发明的较佳实施例而已, 并非用于限定本发明的保 护范围, 凡在本发明的精神和原则之内所作的任何修改、 等同替换和改进 等, 均应包含在本发明的保护范围之内。
Claims
1、 一种 IP多媒体系统 IMS会议媒体数据的加密方法, 其特征在于 , 该方法包括:
终端向服务器通知自身的加密套件信息, 服务器从收到的加密套件信 息中选择待用的加密套件;
终端申请发言权, 并将与服务器所选加密套件对应的加密密钥通知服 务器, 终端经服务器的发言允许后将经过加密的媒体数据发送到服务器。
2、根据权利要求 1所述的 IMS会议媒体数据的加密方法,其特征在于, 所述终端将经过加密的媒体数据发送到服务器后, 该方法进一步包括: 服务器判断参会成员是否具备媒体数据加密能力, 若具备, 则将加密 的媒体数据发送到参会成员终端; 若不具备, 则将加密的媒体数据解密后 发送到参会成员终端。
3、根据权利要求 2所述的 IMS会议媒体数据的加密方法,其特征在于, 所述终端向服务器通知自身的加密套件信息之前, 该方法还包括: 终端在 会话描述协议 SDP信息中添加媒体数据加密能力信息, 并执行与服务器间 的 SDP协商;
相应的, 所述服务器判断参会成员是否具备媒体数据加密能力为: 判 断参会成员终端是否将媒体数据加密能力信息添加在 SDP信息中, 若已添 加, 则具备媒体数据加密能力, 若未添加, 则不具备媒体数据加密能力。
4、根据权利要求 3所述的 IMS会议媒体数据的加密方法,其特征在于, 所述终端在 SDP信息中添加媒体数据加密能力信息, 并执行与服务器间的 SDP协商, 具体为:
终端将添加媒体数据加密能力信息的 SDP信息发送到服务器, 服务器 收到后通知终端;
服务器将会议的媒体编解码集合及具备加密功能的确定信息通知终
终端与服务器进行各自的资源预留操作;
终端更新自身的媒体描述信息并通知服务器, 服务器确定会议的媒体 类型, 并确定是否进行媒体数据加密;
终端与服务器确认 SDP协商完毕。
5、根据权利要求 1至 4中任一项所述的 IMS会议媒体数据的加密方法, 其特征在于, 所述终端向服务器通知自身的加密套件信息, 具体为:
终端与服务器建立安全传输层协议 TLS连接, 之后终端通过发言权控 制协议 BFCP向服务器通知自身的加密套件信息。
6、根据权利要求 1至 4中任一项所述的 IMS会议媒体数据的加密方法, 其特征在于, 所述加密套件信息为: 数据加密标准 DES 中的 3DES、 或高 级加密标准 AES对称加密算法;
所述加密套件信息包含于发言权控制协议 BFCP的报文扩展属性 CIPH ER— SUITE— INFO中;
所述加密密钥包含于 BFCP的报文扩展属性 KEY— DATA— INFO中。
7、 一种 IMS会议媒体数据的加密系统, 其特征在于, 该系统包括: 终 端和服务器; 其中,
所述终端, 用于向服务器通知自身的加密套件信息; 申请发言权, 并 将与服务器所选加密套件对应的加密密钥通知服务器, 经服务器的发言允 许后将经过加密的媒体数据发送到服务器;
所述服务器, 用于从终端发送的加密套件信息中选择待用的加密套件; 接收终端上传的加密密钥及经过加密的媒体数据。
8、根据权利要求 7所述的 IMS会议媒体数据的加密系统,其特征在于, 所述服务器, 进一步用于判断参会成员是否具备媒体数据加密能力, 确定 参会成员具备媒体数据加密能力, 则将加密的媒体数据发送到参会成员终
端; 确定参会成员不具备媒体数据加密能力, 则将加密的媒体数据解密后 发送到参会成员终端; 相应的,
该系统进一步包括参会成员终端, 用于接收服务器下发的加密的媒体 数据, 或接收服务器下发的经服务器解密的媒体数据。
9、根据权利要求 7或 8所述的 IMS会议媒体数据的加密系统, 其特征 在于, 所述终端进一步用于在 SDP信息中添加媒体数据加密能力信息, 并 执行与服务器间的 SDP协商;
相应的, 所述服务器, 进一步用于执行与终端间的 SDP协商。
10、 根据权利要求 9所述的 IMS会议媒体数据的加密系统, 其特征在 于, 所述终端在 SDP信息中添加媒体数据加密能力信息, 并执行与服务器 间的 SDP协商, 具体为:
将添加媒体数据加密能力信息的 SDP信息发送到服务器, 接收服务器 发送的会议的媒体编解码集合及服务器具备加密功能的确定信息, 进行资 源预留操作; 更新自身的媒体描述信息并通知服务器,确认 SDP协商完毕; 相应的, 所述服务器执行与终端间的 SDP协商, 具体为:
接收终端所发的添加媒体数据加密能力信息的 SDP信息, 并通知终端 已接收到添加媒体数据加密能力信息的 SDP信息; 将会议的媒体编解码集 合及具备加密功能的确定信息通知终端, 进行资源预留操作; 接收终端更 新的媒体描述信息, 确定会议的媒体类型, 并确定是否进行媒体数据加密。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910091032.6 | 2009-08-20 | ||
CN200910091032A CN101635919B (zh) | 2009-08-20 | 2009-08-20 | 一种ip多媒体系统会议媒体数据的加密方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2011020332A1 true WO2011020332A1 (zh) | 2011-02-24 |
Family
ID=41594934
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2010/071831 WO2011020332A1 (zh) | 2009-08-20 | 2010-04-16 | 一种ip多媒体子系统会议媒体数据的加密方法及系统 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101635919B (zh) |
WO (1) | WO2011020332A1 (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101635919B (zh) * | 2009-08-20 | 2012-10-10 | 中兴通讯股份有限公司 | 一种ip多媒体系统会议媒体数据的加密方法及系统 |
CN102833742B (zh) * | 2011-06-17 | 2016-03-30 | 华为技术有限公司 | 机器类通信设备组算法的协商方法和设备 |
CN102594794B (zh) * | 2011-12-24 | 2015-04-29 | 华为技术有限公司 | 一种媒体加密会议的接入方法及装置 |
CN108833943B (zh) * | 2018-04-24 | 2020-12-08 | 苏州科达科技股份有限公司 | 码流的加密协商方法、装置及会议终端 |
CN110798710A (zh) * | 2018-08-03 | 2020-02-14 | 视联动力信息技术股份有限公司 | 一种流媒体处理方法和装置 |
CN115134637B (zh) * | 2022-06-29 | 2024-04-12 | 北京奇艺世纪科技有限公司 | 流媒体播放系统、方法、装置、电子设备及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1697368A (zh) * | 2005-06-20 | 2005-11-16 | 中兴通讯股份有限公司 | 一种基于tls的ip多媒体子系统接入安全保护方法 |
CN101102185A (zh) * | 2006-07-06 | 2008-01-09 | 朗迅科技公司 | Ims会话的媒体安全 |
CN101222612A (zh) * | 2007-01-12 | 2008-07-16 | 华为技术有限公司 | 一种安全传输媒体流的方法和系统 |
CN101635919A (zh) * | 2009-08-20 | 2010-01-27 | 中兴通讯股份有限公司 | 一种ip多媒体系统会议媒体数据的加密方法及系统 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100369430C (zh) * | 2005-06-21 | 2008-02-13 | 中兴通讯股份有限公司 | 一种ip多媒体子系统接入安全的保护方法 |
CN100479568C (zh) * | 2006-12-25 | 2009-04-15 | 北京邮电大学 | 智能移动终端上的保密电话实现方案 |
-
2009
- 2009-08-20 CN CN200910091032A patent/CN101635919B/zh not_active Expired - Fee Related
-
2010
- 2010-04-16 WO PCT/CN2010/071831 patent/WO2011020332A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1697368A (zh) * | 2005-06-20 | 2005-11-16 | 中兴通讯股份有限公司 | 一种基于tls的ip多媒体子系统接入安全保护方法 |
CN101102185A (zh) * | 2006-07-06 | 2008-01-09 | 朗迅科技公司 | Ims会话的媒体安全 |
CN101222612A (zh) * | 2007-01-12 | 2008-07-16 | 华为技术有限公司 | 一种安全传输媒体流的方法和系统 |
CN101635919A (zh) * | 2009-08-20 | 2010-01-27 | 中兴通讯股份有限公司 | 一种ip多媒体系统会议媒体数据的加密方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN101635919A (zh) | 2010-01-27 |
CN101635919B (zh) | 2012-10-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9537837B2 (en) | Method for ensuring media stream security in IP multimedia sub-system | |
JP4856723B2 (ja) | メディアサーバと加入者機器との間においてメディアデータを暗号化して伝送するための方法、装置および/またはコンピュータプログラム製品 | |
CN101232368B (zh) | 一种分配媒体流密钥的方法和多媒体子系统 | |
WO2009021441A1 (fr) | Procédé d'émission et de réception, appareil et système pour la politique de sécurité de la session en multidiffusion | |
US9137267B2 (en) | Secure transmission of media during a communication session | |
JP2009543453A (ja) | Imsセッションのためのメディアセキュリティ | |
WO2011022999A1 (zh) | 一种终端对视频会议数据进行加密的方法及系统 | |
WO2005112338A1 (fr) | Procede de distribution de cles | |
WO2011020332A1 (zh) | 一种ip多媒体子系统会议媒体数据的加密方法及系统 | |
KR20120015312A (ko) | 무선 통신 시스템 내의 멀티캐스트 통신 세션과 연관된 메시지의 보안 | |
WO2008040213A1 (fr) | Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication | |
CN101222320B (zh) | 一种媒体流安全上下文协商的方法、系统和装置 | |
CN108833943A (zh) | 码流的加密协商方法、装置及会议终端 | |
CN107251512B (zh) | 用于建立安全通信会话的方法、设备和系统 | |
WO2007048301A1 (fr) | Procede de cryptage pour service mgn | |
WO2013086840A1 (zh) | 两方呼叫转会议的无缝实现方法及装置 | |
WO2011131051A1 (zh) | 一种安全通信协商方法和装置 | |
WO2008083607A1 (fr) | Procédé et système pour transférer de manière sûre un flux multimédia | |
US20080298593A1 (en) | Gateway Shared Key | |
WO2009094813A1 (fr) | Procédé et appareil de négociation de paramètres de sécurité pour sécuriser le flux multimédia | |
KR101121230B1 (ko) | Sip 기반 인터넷 전화 서비스 보안 시스템 및 그 방법 | |
US20200204595A1 (en) | Media protection within the core network of an ims network | |
WO2009094812A1 (fr) | Procédés et appareils pour assurer la sécurité de flux multimédia point à point | |
WO2009094814A1 (fr) | Procédé de génération de paramètres de sécurité pour sécuriser un flux multimédia et appareil associé | |
EP2846510A1 (en) | SRTP protocol extension |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 10809465 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 10809465 Country of ref document: EP Kind code of ref document: A1 |