CN102067554B - Sending secure media streams - Google Patents

Sending secure media streams Download PDF

Info

Publication number
CN102067554B
CN102067554B CN200980122839.XA CN200980122839A CN102067554B CN 102067554 B CN102067554 B CN 102067554B CN 200980122839 A CN200980122839 A CN 200980122839A CN 102067554 B CN102067554 B CN 102067554B
Authority
CN
China
Prior art keywords
hop
context identifier
srtp
media stream
another
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN200980122839.XA
Other languages
Chinese (zh)
Other versions
CN102067554A (en
Inventor
罗尔夫·布洛姆
成怡
约翰·马特森
马茨·内斯隆德
卡尔·诺曼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN102067554A publication Critical patent/CN102067554A/en
Application granted granted Critical
Publication of CN102067554B publication Critical patent/CN102067554B/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • 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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method and apparatus for sending a first secured media stream having a payload via an intermediate node. The intermediate node receives from a sender the first secured media stream. An end-to-end context identifier and a hop-by-hop context identifier are determined for the first secured media stream, where the hop-by-hop context identifier relates to the intermediate node and the end-to-end identifier relates to the sender. A second secured media stream is generated, which includes at least the payload of the first secured media stream and the context identifiers to identify the first secured media stream. The second secured media stream is sent to a receiving node, and the context identifiers are also sent to the receiving node. The context identifiers are usable by the receiving node to recover the first secured media stream.

Description

Send secure media streams
Technical field
The present invention relates to send the field of secure media streams.
Background technology
RTP (RTP) is the agreement for transmit audio and video medium data by packet switching network.RTP is used for transmitting in real time and stream medium data, as interactive audio and video.Therefore, for the application such as such as IPTV, meeting, IP-based voice (VoIP).
The Security Real Time Protocol (SRTP) of formulating in IETF RFC 3711 from March, 2004 is the transmission security agreement of formulating as RTP profile, and a kind of encryption RTP of form is provided.Except encrypt, in clean culture, multicast and broadcasted application, it can also give information integrality and reset protection.The content of SRTP for transmitting between equity side RTP session protection.SRTP is just to protected data between the transmission period between two equity sides at operation SRTP.Especially, once data have been transferred into the end points of SRTP session, no longer protected data of SRTP.In addition, send reciprocity square tube and cross and be encrypted to provide protection to media data, in other words, suppose that sending equity knows all key materials, and be a side of application data protection.
RTP and RTCP (RTP Control Protocol) close association, RTCP can be used for controlling RTP session, and similarly, SRTP has the sisters' agreement that is called safe RTCP (or SRTCP), safe RTCP (or SRTCP) also formulates in RFC 3711.The identical safe correlated characteristic providing to RTP with SRTP is provided to RTCP SRTCP.
The use of SRTP or SRTCP is optional for the use of RTP or RTCP; Even but adopting SRTP/SRTCP, all provided features (as encrypted and certification) are all also optional, and can independently enable or forbid.Exception is message authentication/integrity feature, in the time using SRTCP, needs indispensably this feature.Confidentiality protection in SRTP and SRTCP covers payload, and integrity protection covers payload and whole packet header.
Many content distribution systems and communication service be based on store-and-forward mechanism, and need to be to the end-to-end confidentiality and integrity protection of media.In this case, first media jump by first of transmitter and intermediate storage inter-entity, and then (almost immediately or after a while) is by second jumping from storage entity to second instance.Second instance can be receiver or another intermediate storage entity of expection.But final, media are transferred into the receiver of expection.But every jumping that intermediate node (as storage forwarding server) is located should be subject to integrity protection.(herein, term " jumping " is for representing two, network adjacent internodal logical links in logic.) this is that to allow intermediate node inspection to arrive the authenticity of media data packet of the position of for example mailbox or network answer machine medium needed.This is for preventing that assailant from being necessary with the memory that rubbish fills up on equipment.But it should be disabled for intermediate node that media are decrypted or calculate/revise the necessary key of end-to-end (e2e) integrity protection, to prevent that intermediate node from handling or expressly media data of access.
Another problem is; intermediate node (for example Voice Mailbox) can be processed the message that is all directed to specific recipient but originate in some transmitters; therefore, may need together with carrying out the media of hop-by-hop protection, retransmit some stored stream that also independently carries out e2e protection.If intermediate node produce in this locality will with the stored media that interweave with shielded stream, may produce accessory problem.For example, Voice Mailbox may add to end subscriber the phonetic order of himself, for example, " delete message by 4 ".Usually, the data that also should protect this this locality to produce between server and end subscriber.
The cryptographic parameter that SRTP IETF RFC 3711 use are stored in so-called password context is protected RTP and RTCP.SRTP specifies, and the password context of Media Stream must be by ternary context identifier unique identification:
Context id=<SSRC, destination network address, destination transport port number>, wherein, SSRC is RTP synchronisation source.
For given grouping, receiver must be able to identify the context that should process with it grouping.For this reason, in RTP application, with the part (being SSRC) of in-band method bearer context identifier, and other parts (IP address and port) are " implicit expression " provided by lower level.For the sake of clarity, below describe implicit part is saved from discuss.
Media Stream can join with such context dependent, and described context comprises key and the relevant data of other safety.Context can be used synchronisation source (SSRC) to determine (being designated as SSRC_e2e) in the direct e2e to receiver node encrypts by media data source node.In the time sending Media Stream via intermediate node, will go wrong.First, in the time sending data via the intermediate node that should not access encrypted media, need two kinds of keys: e2e key and hop-by-hop key, wherein, hop-by-hop key is used for verifying the integrality from the media data of front hop node by each intermediate node.But key should be able to not be used for media data to be decrypted.In the time that intermediate node is retransmitted media data to receiver, it can select new random SSRC, and Context identifier failure.Now, the SSRC using between intermediate node and receiver is likely different from the SSRC that former transmitter uses.Because SSRC is for identifying password context at receiver place, receiver can not obtain correct context.
When exist one or more transmitters, should be multiplexed with multiple Media Stream of single shielded stream by intermediate node in the time forwarding to destination time, it is more obvious and complicated that the problems referred to above even become.Even if intermediate node is configured to use the former SSRC of each transmitter, select context still may lead to a conflict based on SSRC_e2e, this is because they are independent by the former transmitter without synchronous by any way of random select.Even if only use a small amount of SSRC, the probability of collision also be can not ignore, and cannot realize reliable Context identifier.
Summary of the invention
The object of the invention is to overcome or at least reduce and send the limitation of secure media streams via intermediate node from sending node to receiving node, and guarantee not access security media of intermediate node.
According to an aspect of the present invention, provide a kind of method that sends first secure media streams with payload via intermediate node.Intermediate node receives described the first secure media streams from transmitter.Determine end-to-end context identifier and hop-by-hop context identifier for described the first secure media streams, described hop-by-hop context identifier is relevant to described intermediate node, and described end-to-end identifier is relevant to described transmitter.Produce the second secure media streams, described the second secure media streams at least comprises the payload of described the first secure media streams and for identifying the described context identifier of described the first secure media streams.Send described the second secure media streams to receiving node, and send described context identifier to described receiving node.Described context identifier can use to recover described the first secure media streams by described receiving node.Use end-to-end and hop-by-hop context identifier allows receiving node to recover the first secure media streams, and intermediate node can not recover the first secure media streams simultaneously.
As a kind of option, intermediate node receives at least another secure media streams from transmitter.In this case, for described another secure media streams, determine another end-to-end context identifier and another hop-by-hop context identifier.Described another hop-by-hop context identifier is relevant to described intermediate node, and described another end-to-end identifier is relevant to described transmitter.Use described context identifier to carry out the payload of at least described the first secure media streams and described another secure media streams multiplexing, described context identifier identifies in safe multiplexed media stream those relevant with described another secure media streams to described the first secure media streams respectively parts.Send described safe multiplexed media stream to described receiving node, and send described another end-to-end context identifier and described another hop-by-hop context identifier to described receiving node.Described context identifier can be used with to described safe multiplexed media stream demultiplexing by described receiving node.This allows receiving node to obtain independently Media Stream from described safe multiplexed media stream.
Alternatively, end-to-end context identifier comprises the identifier relevant to described transmitter.As selectable option, the synchronisation source that described end-to-end context identifier uses from described transmitter is derived, and the synchronisation source that described hop-by-hop context identifier uses from described intermediate node is derived.
Alternatively, in one of contribution source identifier in RTP synchronisation source, RTP header extension and RTP stem, send at least one in context identifier.As selectable option, in one of PRIV field in RTCP Real-time Transport Control Protocol application packet and Security Real Time Protocol stream, send at least one in context identifier.In another option, in SRTP master key identifier label, at least one in receiving node signal notification context identifier.In another option, in the specific field of grouping, send described end-to-end context identifier.
As a kind of option, described receiving node receives described context identifier, receives described secure media streams, and recovers described secure media streams with described context identifier.In the situation that sending multiplexed media stream, alternatively, described method comprises: described receiving node receives described context identifier and described another context identifier, receive described safe multiplexed media stream, and use described context identifier and described another context identifier to described safe multiplexed media stream demultiplexing.
According to a second aspect of the invention, provide a kind of intermediate node for communication network.For described intermediate node provides receiver, for receive the first secure media streams from transmitter.The first context determines that function is configured to, determine end-to-end context identifier and hop-by-hop context identifier for described the first secure media streams, described hop-by-hop context identifier is relevant to described intermediate node, and described end-to-end identifier is relevant to described transmitter.Processing capacity is provided for and produces the second secure media streams, and described the second secure media streams at least comprises the payload of described the first secure media streams and for identifying the described context identifier of described secure media streams.The first sending function is configured to, and sends described the second secure media streams to receiving node; And second sending function be configured to, send described context identifier to described receiving node, described context identifier can use to recover described secure media streams by described receiving node.
As a kind of option, for described intermediate node provides another receiving function, for receiving at least another secure media streams.Another definite function is provided for for described another secure media streams, determines another end-to-end context identifier and another hop-by-hop context identifier.Described another hop-by-hop context identifier is relevant to described intermediate node, and described another end-to-end identifier is relevant to described transmitter.Multiplexing function is provided for and uses described context identifier the payload of described the first secure media streams and described another secure media streams to be carried out multiplexing, and described context identifier identifies those parts relevant to each secure media streams in safe multiplexed media stream.Described the first sending function is configured to send described safe multiplexed media stream to described receiving node, and described the second sending function is configured to send described end-to-end context identifier and described hop-by-hop context identifier to described receiving node, described context identifier can be used with to described safe multiplexed media stream demultiplexing by described receiving node.
Another object of the present invention is to allow receiving node when receive secure media in multiplexed media stream time, to access this secure media.
According to a third aspect of the invention we, provide a kind of receiving node, for receiving the multiplexing secure media streams of deriving from multiple secure media streams.The first receiver is provided for and receives end-to-end context identifier and hop-by-hop context identifier, and described end-to-end context identifier is relevant to transmitter, and described hop-by-hop context identifier is relevant to the intermediate node between media data source and receiver node.Described context identifier is multiplexing for described multiple secure media streams are carried out, and described context identifier identifies those parts relevant to each Media Stream in safe multiplexed media stream.The second receiver is provided for and receives described safe multiplexed media stream, and processor is provided for the described context identifier of use to described safe multiplexed media stream demultiplexing.
According to a forth aspect of the invention, provide a kind of computer program, comprised computer-readable code means, in the time that described computer-readable code means operates on intermediate node, made intermediate node carry out the method as described in above first aspect present invention.
According to a fifth aspect of the invention, provide a kind of computer program, comprised computer-readable medium and as the computer program described in a fourth aspect of the present invention.Described computer program is stored on described computer-readable medium.
Brief description of the drawings
Fig. 1 schematically shows the trust model according to the embodiment of the present invention in block diagram;
Fig. 2 schematically shows the network architecture according to the embodiment of the present invention in block diagram;
Fig. 3 schematically shows the network architecture according to further embodiment of this invention in block diagram, wherein, uses independently SRTP session to send multiple protected media stream;
Fig. 4 schematically shows standard SRTP context;
Fig. 5 schematically shows the SRTP context according to the embodiment of the present invention;
Fig. 6 schematically shows signaling in block diagram, and wherein, multiple received Media Streams are multiplexed with single SRTP Media Stream;
How the context that Fig. 7 schematically shows in single multiplexed media stream changes in time;
Fig. 8 shows according to the signaling diagram of the example signaling of the embodiment of the present invention;
Fig. 9 shows the RTP packet format according to the embodiment of the present invention;
Figure 10 shows according to the signaling diagram of the media in the repeating transmission multiplexed media stream of the embodiment of the present invention;
Figure 11 shows the flow chart of the step of the embodiment of the present invention;
Figure 12 schematically shows the intermediate node according to the embodiment of the present invention in block diagram; And
Figure 13 schematically shows the receiving node according to the embodiment of the present invention in block diagram.
Embodiment
Intermediate node is retransmitted/is forwarded from least one e2e encryption stream of one or more transmitters and the hop-by-hop encryption media of this intermediate node access to receiver.Introduce new identifier and the mapping of the context (e2e context and hop-by-hop context) of unique identification Media Stream.Receiver can recover media content with identifier and mapping, and the in the situation that of multiplexed media stream, receiver can correctly switch between different e2e protection contexts and one or more hop-by-hop context.
The example that intermediate node may need to send the some protected medias stream that is multiplexed with individual session comprises: storage forwarding mailbox or answering machine, for more efficiently content being carried out to local IP access high-speed cache IPTV content and in IPTV application or mix/switch some protected medias stream in VoIP meeting.
Use in the following description following term.
Term " shielded (RTP) media (stream) " refers to the stream/sequence of (RTP) payload of having carried out encryption and/or integrity protection.
Term " SRTP session " refers to according to the RTP/RTCP session of the modification of RFC3711 or RFC3711 (as the expansion in future of RFC3711) protection.
Term " hop-by-hop context " refers to (standard) SRTP context.Hop-by-hop is only for emphasizing that it is when sending or receive when protected media shared context between intermediate node and some other node (another intermediate node or transmission or receiving node).
Term " e2e context " refers to for the code data (key etc.) in create/processing " (as defined above) shielded RTP media " of transmission or receiving node place.Therefore, E2e context is always shared between transmitter and receiver.
Term " the multiplexing context of SRTP " refers to a hop-by-hop context and the contextual combination of one or more e2e.
Note, although SRTP also creates protected media, term defined above " shielded RTP media " not necessarily uses SRTP (or its expansion) to create.Use the motivation of independent term to come from trust model discussed above: intermediate node is not accessed not protected media data by trust, thereby should not be that intermediate node is concerned about for generation of the protection mechanism of protected media, and therefore tackle that it is transparent.In addition, when using time of the present invention, expect intermediate node as far as possible with existing SRTP specification (RFC3711) compatibility, and do not know may be in the expansion of the SRTP of transmitter receiver side hint.
Fig. 1 shows the trust model according to the embodiment of the present invention.Intermediate node needs to use the 2nd SRTP session to retransmit the shielded RTP media that receive as a part for multiple SRTP sessions; described the 2nd SRTP session is independent of the SRTP session using in the time that transmitter receives protected media when intermediate node; when use new SRTP session parameter in the time that receiver forwards protected media; and must not be decrypted and re-encrypted media; particularly, without intermediate node access clear data.Protected media may not use different cryptographic transformations, key and IKMP to send by one or more transmitters in the same time.In same SRTP session between intermediate node and receiver node, the protected media that works the forwarding immediately that starts from intermediate node (or node relevant to intermediate node) can be mixed with the protected media of the delay of being stored by intermediate node.For example, intermediate node can be some callers' " answering machine " of protected media having recorded from using independent SRTP session, and the message that " listening to " stores betides receiver by new independently single SRTP session.
As mentioned above, intermediate node can also be in same SRTP session, sends or interweave its additional media creating in real time or the media with the local storage of plaintext.For example, above-mentioned answering machine can be added the spoken message of himself, with " user interface " of the receipts machine/end subscriber that achieves a butt joint.Another example is, for intermediate node, to add the media advertisement taking receiver/end subscriber as target.
As mentioned above, in the simplest situation, only have a transmitter, this transmitter participates in a SRTP session with intermediate node, comprises the shielded RTP media for given receiver.But, general for fear of losing, below describe more generally situation is discussed, wherein, there is multiple transmitters and relevant safe context.Fig. 2 shows this situation, and wherein, intermediate node 1 receives multiple SRTP sessions from multiple protected media source nodes 2,3,4, and in single SRTP session, sends received protected media to receiver node 5 subsequently.
Typically be subject to e2e Confidentiality protection from some or all the protected media in transmitter 2,3,4, and can be subject to e2e integrity protection.The parameter (key etc.) using and e2e context dependent are shared between each transmitter and final receiver.Can also be to being subject to the media of e2e protection to carry out further hop-by-hop integrity protection (using SRTP), the security parameter that therefore used and hop-by-hop (hbh) context dependent between transmitter and intermediate node 1.Note, protected media can pass through some intermediate nodes, and can require integrity protection to each jumping.Intermediate node 1 inspection is imported the integrality of SRTP session into, and if need to use SRTP to produce the new hop-by-hop integrity protection that spreads out of.
As discussed below, transmitter, receiver and intermediate node need to identify correct context.
Fig. 3 shows and uses independently SRTP session to send to intermediate node 1 situation that some protected medias flow to store and retransmit to receiver 5 as single SRTP session subsequently.Each former SRTP session is associated with iSSRC (entering synchronisation source) by transmitter and intermediate node 1.ISSRC is used for identifying according to SRTP the corresponding hop-by-hop context (Hop-by-hop context) of each stream by middle and each transmitter.Specifically, for j transmitter:
Hop-by-hop context id_j=<iSSRC_j> (formula 1)
As mentioned above, for the sake of clarity, port and IP address in context identifier, have been saved.Intermediate node 1 is stored these iSSRC_j values explicitly with the Media Stream that is subject to accordingly e2e protection.Then (may long after), retransmits the stored different Media Stream that is subject to e2e protection by intermediate node 1 to receiver 5.Intermediate node 1 now can be for selecting SSRC value with the corresponding SRTP session of receiver 5, to meet the different condition of selected SSRC value.Note, it is unique that RTP requires to use SSRC in same RTP session, and in RTP, builds anti-collision mechanism.In order to ensure that receiver 5 is to contextual unique identification, intermediate node 1 creates the iSSRC_j that originally used by transmitter to for example, in the mapping of retransmitting eSSRC_j (going out) value using in SRTP session:
ESSRC_j=F (iSSRC_j, ID_j....) (formula 2)
Wherein, F be for example by comprising transmitter mark (ID_j) even dependence ensure originally also unique mapping of identical each eSSRC_j of two iSSRC_j being used by two transmitters.In other cases, it may be actual making eSSRC_j depend at least partly content designator.For example, in the situation that content is film or song, can comprise the information that identifies songs/movies.Alternatively, function F is selected random eSSRC_j value not existing under the constraint that two eSSRC_j values are identical.Intermediate node 1 is for example by transmitting (iSSRC_j, ID_j, eSSRC_j) tuple of form or (iSSRC_j, ID_j) description and to mapping F used, to receiver (or, if there is more than one intermediate node, to next intermediate node) communication.Now, the SRTP session between intermediate node 1 and receiver 5 is used following formula mark SRTP context:
Hbh context_j=e2e_context_j=<eSSRC_jGreatT.Grea T.GT (formula 3)
Intermediate node 1 can use standard SRTP context.Referring to Fig. 4, as discussed, standard SRTP context has by <IPadr, port, the data structure of SSRC> mark, and comprise the data of describing master key, key element (salt), enciphering transformation, authentication transform and playback lists.But, at receiver side, use " expansion " multiplexing SRTP context to allow e2e and hbh protection.As shown in Figure 5, in one embodiment, by <IPadr, port, hbh_context_ID> identifies the contextual data structure of SRTP.Especially, each context is divided into two parts by receiver 5: hbh part, is public for all multiplexing protected media stream in SRTP, and comprises the contextual list of key element, enciphering transformation, authentication transform, playback lists and e2e.Comprise e2e context part for each multiplexing protected media stream.E2e context comprises the data identical with above-mentioned traditional SRTP context.In other words, receiver 5 uses the SRTP parameter of consulting between centre and receiver to fill hbh part, and for example, fills e2e context with the parameter of (outside band) e2e carrying between each transmitter and receiver.
In the case of sending with stream the media that are not subject to e2e protection, the set of identifier or adopt empty algorithm mark e2e context or do not identify e2e context.
In the time retransmitting protected media, middle basis is mapped in above in RTP grouping SSRC value is set, and protects according to its hbh context application SRTP.Receiver obtains hbh context and e2e context with included SSRC.
Therefore, typically, multiplexing transmission protected media in single SRTP session, but note, can send immediately the media in self-possessed master stream, described media can then merge at receiver place., in new SRTP session, retransmit the each former SRTP session of protected media.
Fig. 6 shows situation in another embodiment, wherein, and multiplexing two protected media streams of storing at intermediate node 1 place, and send to receiver node 5 as single SRTP session.Represent the current e2e context relevant to the protected media of retransmitting from intermediate node 1 with new context identifier C.Can in RTP/RTCP stream or with " outside band ", mode (for example, for example, if supposition intermediate node 1 has been stored the information relevant with former transmitter (their mark) can notify C value how to distribute to receiver 5, use SIP or other control protocols) between intermediate node 1 and receiver 5 with signal notification context identifier C.Identifier C (for example 32-bit number) can comprise the information relevant with the mark of former transmitter and/or former context identifier; but generally intermediate node 1 is selected completely at one's discretion, only needs identifier C for the contextual each relevant former transmitter the 2, the 3rd of relevant protected media/e2e, unique.Especially, value C can not have the explicit dependence of arbitrary former iSSRC that transmitter 2,3 is used or their mark (condition being associated from different C values except optional different transmitters).In either case, now, each e2e context at receiver place by context identifier C unique identification:
E2e context id=<C> (formula 4)
Can use standard SRTP SSRC mechanism as above at the receiver 5 mark hbh of place contexts.This means, use single hbh context and multiple e2e context.Alternatively, can also identify hbh context with C.Current which e2e context that using due to no matter, contextual hbh part keeps fixing, each e2e part is repeated to hbh part may " waste " memory space, and can use above-mentioned with hbh partly and the SRTP context of e2e fractional reuse.
Intermediate node 1 can use identical identifier for its hbh SRTP context.
In the example of Fig. 6, the first transmitter 2 sends the Media Stream with iSSRC_2=17, and the second transmitter 3 sends the Media Stream with iSSRC_3=4711.Intermediate node is stored corresponding protected media stream, and subsequently they is multiplexed with to single SRTP session.Be that the first protected media flow point is mixed context identifier (for example C=1); and for example, for second (distributes (different) context identifier; C=2), therefore receiving node 5 can determine which context is each data flow belong to.As mentioned above, in some cases, make C depend at least partly transmitter mark and/or content designator may be actual.
For the media (for example, by the local media that produce of intermediate node) of non-e2e protection, can use the C-value of special reservation, for example C=0.
Fig. 7 shows context identifier C and how to change in time.In this example, three protected media streams that receive by different SRTP sessions at intermediate node 1 place have been multiplexed with the single SRTP session to receiver 5.Which source context identifier C comes from the data in multiplexed media stream changes.Context identifier C can change by grouping, to allow retransmitting several stream simultaneously.More than discuss and between centre and receiver, transmit C value.
In another embodiment, C-value is included in and sends in the former message of transmitter with in-band method.As mentioned above, intermediate node can use remapping of C-value when to receiver forwarding messages, and for example by specifying the right of (enter-C, go out-C) form, how the mapping of notice receiver realizes.This embodiment in fact with the equivalence shown in Fig. 3, unique difference is, uses additional appointed information field instead of has been present in the SSRC field in RTP stem.
Context identifier C also can be used for the content of mark except safe context, for example, and audio/video codec and codec parameters.
In another embodiment shown in the example of Fig. 8 (can be counted as the combination of the first two embodiment), can identify some context with eSSRC, and can identify other contexts by the context identifier C field in the master key identifier (MKI) of launching, identify other contexts with the combination of eSSRC and context identifier C.Context is by eSSRC, and C is to unique identification:
Hop-by-hop context id=<eSSRC, C> (formula 5)
E2e context id=<eSSRC, C> (formula 6)
Illustrative case is to set up some SRTP sessions but situation that only some session is made up of the multiplexing protected media of the transmitter from more than one when receiver 5 and intermediate node 1.
Identical with two embodiment, between intermediate node 1 and receiver 5, notify C value with in-band method signal.An option is to use SRTP MKI field (for example using (amendment) SRTPMKI field) with the conversion of signal notification context (being that C-value changes).MKI is the variable length field in SRTP grouping, is originally only intended to instruction and uses which key, allows in SRTP context, use multiple master keys and switch to stop between these master keys.But for the present invention, MKI can be used for the more generally form that signal notification context is switched.Especially, the grouping being associated with context C can be used MKI=C etc.
" expansion " MKI label also comprises: the e2e part C of MKI (electing " standard " SRTP MKI as by centre) and context identifier.Now, the MKI label sending to receiver 5 from intermediate node 1 for example can be, Expanded MKI=MKI ‖ C.
Another mode is to be e2e part and hbh part by RTP constructed in groups, as shown in Figure 9.Herein, C field can be carried on (because it must be inserted by intermediate node) after the part that is subject to e2e protection, and therefore C field can be by the protection of hbh part.
Alternatively, can in RTP header extension, send context identifier C.Can in each grouping, send context identifier C, or only in some grouping, send context identifier C and SRTP index, described SRTP index indicate the appointment context that identified by context identifier C by for a SRTP divide into groups.(SRTP index is by RTP sequence number and cycle counter structure, and described cycle counter is held in transmitter and receiver place, conceptive, whenever RTP sequence number circulation primary increases 1).Header extension can also comprise other information such as coding/decoding information.Header extension must be constructed to receiver can be identified as header extension bearer context identifier.In addition, in this embodiment, receiver 5 must check with the authenticating tag of e2e context dependent connection before (in logic) remove header extension, this is because e2e authenticating tag is originally application in the time not there is not expansion.
In another specific embodiment, can in the field of the contribution source of RTP stem (CSRC), send context identifier C.Can in each grouping, send context identifier C, or only in some grouping, send context identifier C and RTP sequence number, described RTP sequence number indicate the appointment context that identified by context identifier C by for a RTP divide into groups.Stem can also comprise other information such as coding/decoding information.CSRC field must be constructed to receiver can be identified as header extension bearer context identifier.Receiver 5 must check with the reach of e2e authenticating tag except CSRC field.
In another specific embodiment, can be in RTCP grouping for example, PRIV field in (general " application data " type (RTCP APP) of grouping) or SRTP SDES packet type send context identifier C (referring to IETF RFC 3550).Because this belongs to out-of-band signalling mechanism more, preferably, send context identifier C together with SRTP index, described SRTP index indicate the appointment context that identified by context identifier C by for a RTP divide into groups.RTCP grouping can also comprise other information such as coding/decoding information.
The key management of intermediate node-receiver link does not belong to scope of the present invention.Owing to forwarding via intermediate node from the Media Stream of multiple e2e transmitters, can find out, use the solution of hop-by-hop key can extend to the hop-by-hop key that end-to-end key is provided and self is used by intermediate node 1 for all transmitters simply.
Typically, sending before any SRTP/SRTCP, send the map information (and other information such as code/decode type) between context identifier C, SSRC and context from intermediate node 1 to receiver 5.In one embodiment, this can be by for example comprising that information completes being carried on the SDP that SIP sets up in signaling.For example, possible realization is to add " a-is capable " to SDP, under the row providing for the key management information of specific medium, lists context identifier.If necessary, can during ongoing session, send that upgrade or new mapping.Can also be for example in header extension, CSRC field or send map information with in-band method via RTCP.Signaling diagram is shown in Figure 10, has shown the intermediate node of retransmitting two streams.In this example, one in stream is delayed, and one by forwarding immediately.
Figure 11 shows the step of the embodiment of the present invention.Below number the numbering corresponding to Figure 11.
S1. intermediate node 1 receives secure media streams from transmitter.In certain embodiments, intermediate node can receive multiple secure media streams from one or more transmitters.
S2. intermediate node (based on eSSRC and/or C-value) is determined end-to-end and hop-by-hop context identifier, described context identifier mark secure media streams.
S3. intermediate node produces the second secure media streams, and in certain embodiments, the second secure media streams is the multiplexed media stream that comprises multiple secure media streams.The second secure media streams comprises the payload of at least the first secure media streams and identifies the context identifier of each secure media streams.
S4. send the second secure media streams to receiving node 5.
S5. send context identifier to receiving node, to allow receiving node to recover each secure media streams.
Turn to Figure 12 below, schematically show intermediate node 1.Intermediate node 1 has receiver 6, for receiving at least one secure media streams via SRTP session.Provide context to determine function 7, to determine end-to-end context identifier and hop-by-hop context identifier for each secure media streams.The second processor 8 (can be a part for first processor or independent processor) is configured to, produce the second Media Stream with context identifier, to identify those parts relevant to each secure media streams in the second Media Stream, described the second Media Stream can comprise multiplexing multiple Media Streams.The first sending function 9 is provided for and uses SRTP session to send the second secure media streams to receiver node 5, and the second sending function 10 is provided for to receiver node 5 and sends end-to-end context identifier and hop-by-hop context identifier.This allows receiving node 5 (if necessary, by the protected media stream demultiplexing to multiplexing) to obtain the first secure media streams.Also, for intermediate node 1 provides the computer program that adopts memory 11 forms, memory 11 is for storing computer program, and described computer program has the instruction that can be used to carry out by intermediate node 1 above-mentioned functions.
Figure 13 shows receiving node 5, for receiving node 5 provides the first receiver 12, for receiving context identifier.The second receiver 13 is provided for and uses SRTP session to receive the multiplexing protected media stream of safety, and processor 14 is provided for use context identifier to received protected media stream demultiplexing.Another media processing function 15 is provided for deciphering and otherwise processes the protected media stream of demultiplexing.
The invention describes two kinds of different safeguard protection contexts: e2e context and hop-by-hop context.They can combine realization as multiplexing SRTP context at receiver place.Multiplexingly realized by new context identifier.This identifier is based on SSRC field, new identifier C or its combination, and for identifying current context.In the MKI that context identifier C can be in stem, header extension, launch or in any other specific field of RTP grouping, notify with signal.
As discussed above, it should be noted in the discussion above that with regard to IP address and port, conventional SRTP context identifier part is outside implicit expression/band.For clarity sake, above description is paid close attention to and is processed as e2e context identifier in the band of C value or SSRC equivalent-load.Also expect to point out, e2e context identifier can have the outer part of implicit expression/band, as: transmitter mark, content identification (" title " of such as film or song) etc., do not belong to scope of the present invention to the processing of these parts.
One of ordinary skill in the art will recognize, can under the prerequisite that does not deviate from the scope of the invention, carry out various amendments to above-described embodiment.

Claims (13)

1. a method that sends the first Security Real Time Protocol SRTP Media Stream with payload via intermediate node, comprising:
At described intermediate node place, receive a described SRTP Media Stream from transmitter;
Determine end-to-end context identifier and hop-by-hop context identifier for a described SRTP Media Stream, described hop-by-hop context identifier is relevant to described intermediate node, and described end-to-end context identifier is relevant to described transmitter;
Produce the 2nd SRTP Media Stream, described the 2nd SRTP Media Stream at least comprises the payload of a described SRTP Media Stream and for identifying described end-to-end context identifier and the described hop-by-hop context identifier of a described SRTP Media Stream;
Send described the 2nd SRTP Media Stream to receiving node; And
Send described end-to-end context identifier and described hop-by-hop context identifier to described receiving node, described end-to-end context identifier and described hop-by-hop context identifier can use to recover a described SRTP Media Stream by described receiving node.
2. method according to claim 1, also comprises:
At described intermediate node place, receive at least another SRTP Media Stream from transmitter;
For described another SRTP Media Stream, determine another end-to-end context identifier and another hop-by-hop context identifier, described another hop-by-hop context identifier is relevant to described intermediate node, and described another end-to-end context identifier is relevant to described transmitter;
Use described another end-to-end context identifier and described another hop-by-hop context identifier to carry out the payload of an at least described SRTP Media Stream and described another SRTP Media Stream multiplexing, described another end-to-end context identifier and the part relevant with described another SRTP Media Stream to a described SRTP Media Stream respectively in described another hop-by-hop context identifier mark SRTP multiplexed media stream;
Send described SRTP multiplexed media stream to described receiving node; And
Send described another end-to-end context identifier and described another hop-by-hop context identifier to described receiving node, described another end-to-end context identifier and described another hop-by-hop context identifier can be used with to described SRTP multiplexed media stream demultiplexing by described receiving node.
3. method according to claim 1, wherein, described end-to-end context identifier comprises the identifier relevant to described transmitter.
4. method according to claim 1, wherein, the synchronisation source that described end-to-end context identifier uses from described transmitter is derived, and the synchronisation source that described hop-by-hop context identifier uses from described intermediate node is derived.
5. according to the method described in any one in claim 1 or 4, also comprise: in one of contribution source identifier in RTP synchronisation source, RTP header extension and RTP stem, send at least one in described end-to-end context identifier and described hop-by-hop context identifier.
6. according to the method described in any one in claim 1 or 4, also comprise: in one of PRIV field in RTCP Real-time Transport Control Protocol application packet and Security Real Time Protocol stream, send at least one in described end-to-end context identifier and described hop-by-hop context identifier.
7. according to the method described in any one in claim 1 or 4, also comprise: in SRTP master key identifier label, notify at least one in described end-to-end context identifier and described hop-by-hop context identifier to receiving node with signal.
8. also comprise according to the method in any one of claims 1 to 3: in the specific field of grouping, send described end-to-end context identifier.
9. according to the method in any one of claims 1 to 3, also comprise: at described receiving node place,
Receive described end-to-end context identifier and described hop-by-hop context identifier;
Receive described the 2nd SRTP Media Stream;
Recover described the 2nd SRTP Media Stream with described end-to-end context identifier and described hop-by-hop context identifier.
10. method according to claim 2, also comprises: at described receiving node place,
Receive described end-to-end context identifier and described hop-by-hop context identifier and described another end-to-end context identifier and described another hop-by-hop context identifier;
Receive described SRTP multiplexed media stream;
Use described end-to-end context identifier and described hop-by-hop context identifier and described another end-to-end context identifier and described another hop-by-hop context identifier to described SRTP multiplexed media stream demultiplexing.
11. 1 kinds of intermediate nodes for communication network, described intermediate node comprises:
The first receiver, for receiving a SRTP Media Stream from transmitter;
Functional entity determined in the first context, for determining end-to-end context identifier and hop-by-hop context identifier for a described SRTP Media Stream, described hop-by-hop context identifier is relevant to described intermediate node, and described end-to-end context identifier is relevant to described transmitter;
Processing capacity entity, for generation of the 2nd SRTP Media Stream, described the 2nd SRTP Media Stream at least comprises the payload of a described SRTP Media Stream and for identifying described end-to-end context identifier and the described hop-by-hop context identifier of a described SRTP Media Stream;
The first sending function entity, for sending described the 2nd SRTP Media Stream to receiving node; And
The second sending function entity, for sending described end-to-end context identifier and described hop-by-hop context identifier to described receiving node, described end-to-end context identifier and described hop-by-hop context identifier can use to recover a described SRTP Media Stream by described receiving node.
12. intermediate nodes according to claim 11, also comprise:
The second receiver, for receiving at least another SRTP Media Stream;
Functional entity determined in the second context, be used for for described another SRTP Media Stream, determine another end-to-end context identifier and another hop-by-hop context identifier, described another hop-by-hop context identifier is relevant to described intermediate node, and described another end-to-end identifier is relevant to described transmitter;
Multiplexing functional entity, multiplexing for using described another end-to-end context identifier and described another hop-by-hop context identifier to carry out the payload of an at least described SRTP Media Stream and described another SRTP Media Stream, described another end-to-end context identifier and the part relevant to each SRTP Media Stream in described another hop-by-hop context identifier mark SRTP multiplexed media stream;
Wherein, described the first sending function entity is configured to send described SRTP multiplexed media stream to described receiving node; And
Described the second sending function entity is configured to send described another end-to-end context identifier and described another hop-by-hop context identifier to described receiving node, and described another end-to-end context identifier and described another hop-by-hop context identifier can be used with to described SRTP multiplexed media stream demultiplexing by described receiving node.
13. 1 kinds of receiving nodes, for receiving the SRTP multiplexed media stream deriving from multiple SRTP Media Streams, described receiving node comprises:
The first receiver, be used for receiving end-to-end context identifier and hop-by-hop context identifier, described end-to-end context identifier is relevant to transmitter, described hop-by-hop context identifier is relevant to the intermediate node between media data source and described receiving node, described end-to-end context identifier and described hop-by-hop context identifier are multiplexing for described multiple SRTP Media Streams are carried out, to identify part relevant to each Media Stream in SRTP multiplexed media stream;
The second receiver, for receiving described SRTP multiplexed media stream;
Processor, for using described end-to-end context identifier and described hop-by-hop context identifier to described SRTP multiplexed media stream demultiplexing.
CN200980122839.XA 2008-06-16 2009-02-20 Sending secure media streams Expired - Fee Related CN102067554B (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US6185408P 2008-06-16 2008-06-16
US61/061,854 2008-06-16
PCT/EP2009/052078 WO2009153072A1 (en) 2008-06-16 2009-02-20 Sending secure media streams

Publications (2)

Publication Number Publication Date
CN102067554A CN102067554A (en) 2011-05-18
CN102067554B true CN102067554B (en) 2014-06-18

Family

ID=40600095

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200980122839.XA Expired - Fee Related CN102067554B (en) 2008-06-16 2009-02-20 Sending secure media streams

Country Status (4)

Country Link
US (1) US8966105B2 (en)
EP (1) EP2304916A1 (en)
CN (1) CN102067554B (en)
WO (1) WO2009153072A1 (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8504718B2 (en) * 2010-04-28 2013-08-06 Futurewei Technologies, Inc. System and method for a context layer switch
WO2012057796A1 (en) * 2010-10-29 2012-05-03 Proximic, Inc. Method for transmitting information from a first information provider to a second information provider via an information intermediary
US9998429B2 (en) 2010-10-29 2018-06-12 Proximic, Llc. Method for transmitting information from a first information provider to a second information provider via an information intermediary
CN103475639A (en) * 2013-08-09 2013-12-25 杭州华三通信技术有限公司 RTP (Real-time Transport Protocol) backspacing method and apparatus
CN103475640A (en) * 2013-08-09 2013-12-25 杭州华三通信技术有限公司 Method and apparatus for realizing RTP (Real-time Transport Protocol) backspacing
EP2846510A1 (en) * 2013-09-09 2015-03-11 Alcatel Lucent SRTP protocol extension
US10819524B2 (en) * 2016-10-19 2020-10-27 Qualcomm Incorporated Methods for header extension preservation, security, authentication, and protocol translation for RTP over MPRTP
US11483295B2 (en) * 2018-12-05 2022-10-25 Citrix Systems, Inc. Method for securely negotiating end-to-end cryptographic context using inline messages through multiple proxies in cloud and customer environment
US11005585B1 (en) * 2019-12-31 2021-05-11 Juniper Networks, Inc. Transporting client timing information across a network
KR20230002347A (en) * 2020-04-24 2023-01-05 소니 세미컨덕터 솔루션즈 가부시키가이샤 Transmitting device, receiving device and communication system
US12052229B2 (en) 2021-07-30 2024-07-30 Cisco Technology, Inc. Secure frame encryption as a service
CN114979094B (en) * 2022-05-13 2024-06-07 深圳智慧林网络科技有限公司 RTP-based data transmission method, device, equipment and medium

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045033A1 (en) * 2004-10-20 2006-04-27 Hewlett-Packard Development Company, L. P. Methods and systems that use information about encrypted data packets to determine an order for sending the data packets
CN101043478A (en) * 2007-04-20 2007-09-26 北京航空航天大学 Service gateway and method for realizing message safe process
CN101197674A (en) * 2007-12-10 2008-06-11 华为技术有限公司 Encrypted communication method, server and encrypted communication system

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7069335B1 (en) * 1999-08-10 2006-06-27 Microsoft Corporation Method and system for exchanging messages between entities on a network comprising an actor attribute and a mandatory attribute in the header data structure
US7058728B1 (en) * 1999-10-29 2006-06-06 Nokia Corporation Method and apparatus for initiating compression of headers of packets and refreshing the context related to the packets
FI111493B (en) * 2000-09-22 2003-07-31 Nokia Corp Defining a Contextual Tag in Compression of Header Fields
US7149230B2 (en) * 2002-03-08 2006-12-12 Microsoft Corporation Transport processor for processing multiple transport streams
US7308101B2 (en) * 2004-01-22 2007-12-11 Cisco Technology, Inc. Method and apparatus for transporting encrypted media streams over a wide area network
CN100574185C (en) * 2005-01-07 2009-12-23 华为技术有限公司 The method that in the IP multimedia service subsystem network, ensures media stream safety
US7852783B2 (en) * 2006-12-07 2010-12-14 Cisco Technology, Inc. Identify a secure end-to-end voice call
US7912217B2 (en) * 2007-03-20 2011-03-22 Cisco Technology, Inc. Customized advertisement splicing in encrypted entertainment sources
US8385234B2 (en) * 2007-03-29 2013-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Media stream setup in a group communication system
US20090103737A1 (en) * 2007-10-22 2009-04-23 Kim Poong Min 3d sound reproduction apparatus using virtual speaker technique in plural channel speaker environment
US8095680B2 (en) * 2007-12-20 2012-01-10 Telefonaktiebolaget Lm Ericsson (Publ) Real-time network transport protocol interface method and apparatus

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045033A1 (en) * 2004-10-20 2006-04-27 Hewlett-Packard Development Company, L. P. Methods and systems that use information about encrypted data packets to determine an order for sending the data packets
CN101043478A (en) * 2007-04-20 2007-09-26 北京航空航天大学 Service gateway and method for realizing message safe process
CN101197674A (en) * 2007-12-10 2008-06-11 华为技术有限公司 Encrypted communication method, server and encrypted communication system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
End-to-middle Security in the Session Initiation Protocol (SIP) draft-ietf-sip-e2m-sec-06;K. Ono等;《SIP Internet-Draft》;20070707;第1-30页 *
H. Schulzrinne等.RTP: A Transport Protocol for Real-Time Applications.《Standards Track RFC3550》.2003,第45-54页. *
K. Ono等.End-to-middle Security in the Session Initiation Protocol (SIP) draft-ietf-sip-e2m-sec-06.《SIP Internet-Draft》.2007,第1-30页.

Also Published As

Publication number Publication date
WO2009153072A1 (en) 2009-12-23
US8966105B2 (en) 2015-02-24
EP2304916A1 (en) 2011-04-06
CN102067554A (en) 2011-05-18
US20110093609A1 (en) 2011-04-21

Similar Documents

Publication Publication Date Title
CN102067554B (en) Sending secure media streams
US11100197B1 (en) Secure web RTC real time communications service for audio and video streaming communications
CN105594219B (en) Transmitting/reception processing device and method for broadcast singal
RU2541914C2 (en) Method of controlling decoders of at least one group of decoders having access to audiovisual data
CN102474518B (en) For tactful transfer method and the device of Session Hand-off
EP2304918B1 (en) Sending media data via an intermediate node
CN106850681B (en) Method and system for communicating messages
US9992177B2 (en) Method and system for modifying an authenticated and/or encrypted message
CN104040993A (en) Method for sending respectively receiving media stream
US8990563B2 (en) Sending protected data in a communication network
CN106233735A (en) Multicast Flows transmits
CN106464932A (en) Multicast streaming
CN114785622B (en) Access control method, device and storage medium for multi-identification network
US8509433B2 (en) Method and apparatus of generating encryption key for broadcast encryption
CN102577231B (en) Sending protected data in a communication network
US20110314511A1 (en) Provision of Marked Data Content to User Devices of a Communications Network
CN101227272A (en) System and method for obtaining media stream protection cryptographic key
CN102905199B (en) A kind of multicast service realizing method and equipment thereof
CN110061962A (en) A kind of method and apparatus of video stream data transmission
US20040122975A1 (en) Communication of electronic data via a network infrastructure
CN102594794A (en) Access method and device of media encryption conference
CN101247218B (en) Safety parameter negotiation method and device for implementing media stream safety
Hanatani et al. Secure multicast group management and key distribution in IEEE 802.21
CN116112202A (en) Method for realizing encryption and decryption of Ethernet data by adopting self-learning self-organizing mode
CN102833230B (en) A kind of method and system of encrypted group broadcast data

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20140618

Termination date: 20190220