CN101183935A - Cipher key negotiation method, device and system of RTP packet - Google Patents
Cipher key negotiation method, device and system of RTP packet Download PDFInfo
- Publication number
- CN101183935A CN101183935A CNA2007101953902A CN200710195390A CN101183935A CN 101183935 A CN101183935 A CN 101183935A CN A2007101953902 A CNA2007101953902 A CN A2007101953902A CN 200710195390 A CN200710195390 A CN 200710195390A CN 101183935 A CN101183935 A CN 101183935A
- Authority
- CN
- China
- Prior art keywords
- key agreement
- party
- information
- message
- key
- 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.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
The invention embodiment provides a key negotiation method and a device of an RTP message; wherein, the method comprises the following step: a first party and a second party of the key negotiation negotiate the key for encrypting the RTP message by use of an RTCP message. Based on the key negotiation for RTCP message, which is supported by the prior communication system and most communication devices in the system, the technical proposal provided by the invention embodiment need not to reform the prior network, and is able to achieve a broad support prospect.
Description
Technical field
The present invention relates to communication technical field, relate in particular to cryptographic key negotiation method, the Apparatus and system of a kind of RTP (RTP, RealtimeTransport Protocol) message.
Background technology
In the communication system,, the real-time of message transmission is had relatively high expectations as in real time mutual voice and video or the like business.RTP since its can support information the real-time transmission, therefore, in the business that is widely used in the real-time of message transmission is had relatively high expectations.When carrying out real time business, between each communication party, send service related information to opposite end by the RTP message.
Based on RTP message transmissions real time business relevant information the time, matching used RTP Control Protocol (RTCP, RTP Control Protocol), the quality of service of rtp streaming that can the real time monitoring correspondence is as monitoring data transmission rate, propagation delay time or the like.Though RTP can satisfy the real-time requirement of message transmission,, RTP can not ensure the fail safe of message transmission.Also just be used for the monitoring traffic quality with the matching used RTCP of RTP, can not be used to guarantee the fail safe of message transmission equally.Therefore, when carrying out real time business,, make malicious user steal service related information easily because of the fail safe of message transmission is difficult to be protected based on RTP.
In the message transmitting procedure, adopt the way that message transmission is encrypted usually, to ensure the fail safe of message transmission.Before message is encrypted, communicating pair or in many ways between, need to consult can be used for the key of encryption and decryption message, on the one hand, before sending message, the encryption keys message that utilization consults, on the one hand, after receiving encrypted message, utilize the decruption key decrypted message, thereby,, also be difficult to know easily message content because of message is encrypted even malicious user intercepts the message that carries service related information.
In the prior art, the approach that carries out key agreement between the communication parties mainly comprises two kinds: a kind of is the key agreement of signaling plane, often is called the outer negotiation of band, promptly in call establishment, carries out key agreement by the relevant signaling of call setup; Another kind is the key agreement of loading end, often is called in the band to consult, and promptly behind the call setup, communicating pair carries out key agreement in the process of transport service relevant information.
The outer negotiation of above-mentioned band carried out key agreement owing to need carry key agreement information by signaling, therefore, this approach mainly realizes the transmission of key agreement relevant information by the interface parameters that expands signaling plane, but the expanded signalling face need be changed standard on the one hand, second aspect, because practical application scene difference, the process of key agreement may be different, and the way of expanded signalling face also is unfavorable for standardization.
Adopt in the band and consult, then can avoid the expanded signalling face.But the implementation of arranging key is more in the current relevant band, still fails to form negotiation scheme in the comparatively general band.In addition, though standard has provided scheme how to utilize secret key encryption RTP message, promptly safe RTP (SRTP, Secure RTP) scheme for how producing the key that is used to encrypt the RTP message, does not provide corresponding scheme in the standard.
Therefore, need provide the stronger key agreement scheme of a kind of versatility, to be used for encryption to the RTP message.
Summary of the invention
The embodiment of the invention provides a kind of key of RTP message to determine method, and described key is used for the message encryption that sends or is used for the message that receives is deciphered, and this method comprises:
Described first party generates the first key agreement information, and the RTCP message that carries the described first key agreement information is sent to described second party; The required key algorithm of the described first key agreement information and the described key of the calculating that sets in advance is corresponding;
Described first party receives the RTCP message that carries the second key agreement information corresponding with described algorithm that described second party sends; The described second key agreement information utilizes the described first key agreement information to generate by described second party;
Described first party is utilized described first key agreement information and the described second key agreement information, according to the described key of described algorithm computation.
The embodiment of the invention provides a kind of key of RTP message to determine device, comprising: first information generation unit, first packet sending unit, the first message receiving element and first computing unit;
Described first information generation unit generates the key algorithm corresponding first key agreement information required with the described key of the calculating that sets in advance;
Described first packet sending unit will be carried by the RTCP message by the first key agreement information of described first information generation unit generation, and this RTCP message is sent to the key agreement second party;
The described first message receiving element receives the RTCP message that carries the second key agreement information corresponding with described algorithm that described second party sends; The described second key agreement information utilizes the described first key agreement information to generate by described second party;
Described first computing unit utilizes the described first key agreement information of described first information generation unit generation and the described second key agreement information that the described first message receiving element receives, according to the described key of described algorithm computation.
The embodiment of the invention provides a kind of key of RTP message to determine device, comprising: second information generating unit, second packet sending unit, the second message receiving element and second computing unit;
The described second message receiving element receives the RTCP message of the first corresponding key agreement information of the required key algorithm of the described key of the calculating of carrying with setting in advance that the key agreement first party sends; The described first key agreement information is generated by described first party;
Described second information generating unit, the described first key agreement information of utilizing the described second message receiving element to receive generates the second key agreement information corresponding with described algorithm;
Described second packet sending unit will be carried by the RTCP message by the second key agreement information of described second information generating unit generation, and this RTCP message is sent to described first party;
Described second computing unit utilizes the described second key agreement information of described second information generating unit generation and the described first key agreement information that the described second message receiving element receives, according to the described key of described algorithm computation.
In the technical scheme that the embodiment of the invention provides, utilize the RTCP message between key agreement first party and the second party, the needed key agreement information of key agreement is carried to the other side, realize the key agreement between key agreement one side and the second party.In the embodiment of the invention, owing to can carry out alternately based on RTCP between key agreement one side and the second party, with arranging key, and because the existing communication system can support RTCP usually, most communication equipments in the communication system can be supported RTCP, therefore, the technical scheme that the embodiment of the invention provides is because of needing to transform existing network, and has the prospect that can access extensive support.And, in the technical scheme that the embodiment of the invention provides, consult symmetric key between key agreement one side and the second party, the just key agreement information of between key agreement one side and second party, transmitting, and be not key, therefore, can guarantee the fail safe of key.
Description of drawings
Fig. 1 is the schematic diagram of RTP/RTCP message protocol stack;
Fig. 2 is the cryptographic key negotiation method flow chart of a kind of RTP message in the embodiment of the invention;
Fig. 3 is the schematic diagram of cipher key agreement process experience four-stage in the embodiment of the invention;
Fig. 4 is the structural representation of the key agreement device of a kind of RTP message in the embodiment of the invention;
Fig. 5 is the key agreement device of another kind of RTP message in the embodiment of the invention;
Fig. 6 is the flow chart of arranging key between user A and the user B in the embodiment of the invention.
Embodiment
Below in conjunction with accompanying drawing the technical scheme that the embodiment of the invention provides is described in further detail.
Referring to Fig. 1, Fig. 1 is the schematic diagram of RTP/RTCP message protocol stack.Wherein, RTP message and RTCP message all are based on the message of UDP, and the corresponding RTCP message of each RTP message, and corresponding relation can be by udp port number embodiment, the port numbers that the RTP message uses adds one, can obtain the corresponding employed port numbers of RTCP message.Therefore, can more easily find corresponding RTP message by the RTCP message.In the embodiment of the invention, for generation is used to encrypt the key of RTP message, the RTCP that can both support based on current most communication equipments between key agreement one side and key agreement second party, utilizes the RTCP message, consults to be used to encrypt the key of RTP message.
Referring to Fig. 2, Fig. 2 is the cryptographic key negotiation method flow chart of a kind of RTP message in the embodiment of the invention, and this flow process can may further comprise the steps:
In the embodiment of the invention, consult symmetric key between key agreement first party and the second party, correspondingly, can set in advance key algorithm between key agreement first party and the second party, before both sides' computation key, initiate key agreement earlier by first party, send the first key agreement information to second party, thus the beginning arranging key.During specific implementation, can adopt state machine to indicate cipher key agreement process, as in the RTCP message that carries the first key agreement information, the key agreement status indication is set, and this is set is labeled as the negotiation initial state, after thereby second party was received this RTCP message, the implication that can know this first key agreement information was for the required key agreement information of beginning arranging key, as algorithm relevant parameter or the like.
So-called correspondence is to say, key, is calculated based on the key algorithm of both sides' agreement as first party and second party normally by the key agreement both sides, and, when computation key, both sides remove the key algorithm that need know agreement, also need to know some parameters for related in this key algorithm, how many parameter values that the other side got is, these parameter values are key agreement information, and correspondingly, the key agreement informational needs is corresponding with algorithm.
Second party can be based on the first key agreement information of receiving, generate the second key agreement information, again the second key agreement information is sent to a side by the RTCP message, this RTCP message that second party sends can be the response to the RTCP message of receiving side transmission, and the key agreement state in this RTCP message of second party transmission is set to consult the affirmation state.
In addition, at the second party place, second party can be utilized described first key agreement information and the described second key agreement information, according to the described key of described algorithm computation.
In the embodiment of the invention, key agreement first party and second party based on identical key algorithm and identical key agreement information, are calculated identical key, can claim this key for sharing key.
In the embodiment of the invention, because first party is relative with second party, therefore, in the practical application, can appear in the same cipher key agreement process, first party and second party all send to the other side and carry key agreement information and the key agreement state is the RTCP message of consulting beginning, for the purpose of difference, the key agreement state that can claim second party to send is to consult in the RTCP message of beginning, and entrained key agreement information is the 3rd key agreement information.After the first key agreement information that first party will generate occurring and send to second party by the RTCP message as meeting, the 3rd key agreement information that second party will generate sends to the situation of first party by the RTCP message.This situation can cause the key agreement both sides to be difficult to calculate shared key.
At above-mentioned situation, can set in advance selective rule, first party and second party are observed this rule jointly.This rule can be, among the key agreement both sides, the size of each side's comparison self and the other side's IP address, which side IP address is big, determine then that reservation promptly preserves this side generation with the corresponding key agreement information of key agreement initial state, and abandon that second party generates with the corresponding key agreement information of key agreement initial state.Perhaps, this rule also can be, agreement keep preserve promptly that a certain side generates with the corresponding key agreement information of key agreement initial state, and abandon the second party generation with the corresponding key agreement information of key agreement initial state.In the practical application, also can this rule be set according to actual conditions.In the embodiment of the invention, establish and adopt the relatively rule of IP address size, and establish the IP address of the IP address of above-mentioned first party correspondence greater than the second party correspondence.
In the embodiment of the invention,, can be that the header field of this message is identical with the header field of RTCP message with reference to the existing newly-installed key agreement message of RTCP message format for the RTCP message that carries key agreement information.
In the practical application, for the purpose of making things convenient for, can be provided with and carry the key agreement message of key agreement information based on the message of application (APP) type that has the definition of RTCP message now.The APP message can make things convenient for the user that it is expanded with beared information.Existing APP message format is as follows:
0?1?2?3?4?5?6?7?8?9?0?1?2?3?4?5?6?7?8?9?0?1?2?3?4?5?6?7?8?9?0?1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|subtype?| PT＝APP＝204?| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent?data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+。
To wherein subtype (Subtype) field with use and rely on data (Application-dependentdata) field to be described further.The Subtype field is to be used for identifying this APP type of message, and the APP type of message that different Subtype sign is different is that 1 APP message is used for consulting the RTP compression parameters as subtype.In the embodiment of the invention, needing the new Subtype value of definition, is the key agreement message to indicate this APP message, and this new Subtype value can obtain by the mode to the normal structure application in actual applications.Application-dependent data field is represented the specifying information that this message is entrained.
In the embodiment of the invention, the form of definition key agreement message is as follows:
0?1?2?3?4?5?6?7?8?9?0?1?2?3?4?5?6?7?8?9?0?1?2?3?4?5?6?7?8?9?0?1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V＝2|P|subtype?| PT＝APP＝204| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name?(ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|?Type |State |Data(TLV)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+。
In the embodiment of the invention, the Subtype field value is taken as 6; Message name (Name) can extend this as RTP key (RTP Key); Application-dependent data field comprises algorithm types (Type), negotiation state (State) field and data (Data) field.The type field takies a byte, can be used to indicate the key of use to produce algorithm.In the embodiment of the invention, the key algorithm that is adopted is the DH algorithm, and the type field value is 1.In the practical application,, the type field value can be set accordingly if adopt other algorithms.In the embodiment of the invention, state field is the key agreement status indication that is provided with in the APP message, represents that with this message of mark key agreement is to enter which state or stage.In the practical application, if the key algorithm difference that adopts, then in the Application-dependent data field, the also corresponding difference of the message format behind the Type, the State and Data (TLV) field that may not be exactly in the embodiment of the invention to be comprised.
For the DH algorithm, be example with key agreement one side, cipher key agreement process need experience four-stage, and referring to Fig. 3, Fig. 3 is the schematic diagram of cipher key agreement process experience four-stage in the embodiment of the invention.Accordingly, key agreement one side, and the state of the key agreement APP message that transmits between the key agreement second party can comprise following four kinds of states: " 0 " represents non-activation (Dead) state, under this state, the key agreement both sides do not set up as yet and call out, and one side is rolled off the production line as key agreement; Consult beginning (Init) state, key agreement one side reach the standard grade, and sends the first key agreement information to second party, carries in the APP message of this first key agreement information, and the state field value is " 1 "; Consult to confirm (ACK) state, key agreement one side receives the second key agreement information that second party is returned, and carries in the APP message of this second key agreement information, and the state field value is " 2 "; Consult to finish (Finish) state, key agreement one side sends the success of APP message notifying second party key agreement, and in this APP message, the state field value is " 3 ".Correspondingly, can be state field and distribute 4 bits (bits).The Data field is filled in the TLV mode, promptly comprises data type (Type), data length (Length) and numerical value (Value).
In the embodiment of the invention, after the key agreement success, after promptly a side and second party all calculate and share key, both sides can utilize and share the RTP message that secret key encryption will send, for how utilizing the specific practice of sharing secret key encryption RTP message, can not give unnecessary details referring to the SRTP technology.
The embodiment of the invention also provides a kind of key agreement device of RTP message, this device can corresponding above-mentioned key agreement one side, referring to Fig. 4, Fig. 4 is the structural representation of this device, can comprise: first information generation unit, first packet sending unit, the first message receiving element and first computing unit; Wherein,
First information generation unit generates the key algorithm corresponding first key agreement information required with the described key of the calculating that sets in advance;
First packet sending unit will be carried by the RTCP message by the first key agreement information of described first information generation unit generation, and this RTCP message is sent to the key agreement second party;
The first message receiving element receives the RTCP message that carries the second key agreement information corresponding with described algorithm that described second party sends; The described second key agreement information utilizes the described first key agreement information to generate by described second party;
First computing unit utilizes the described first key agreement information of described first information generation unit generation and the described second key agreement information that the described first message receiving element receives, according to the described key of described algorithm computation.
This key agreement one side further can comprise: first state set unit is provided with the key agreement state in the RTCP message that described first packet sending unit sends.
This key agreement one side further can comprise: first information processing unit;
Described first state set unit is provided with in the RTCP message that carries the first key agreement information that described first packet sending unit sends the key agreement state for consulting initial state;
The described first message receiving element, the RTCP message that carries the 3rd key agreement information that described second party generates that receives further that described second party sends, and the key agreement state in this RTCP message is for consulting initial state;
Described first information processing unit according to the rule that sets in advance, determines that the described first key agreement information is effective.
First information processing unit can comprise: first comparing unit and first memory cell;
First comparing unit, the IP address of the IP address of described device greater than described second party determined in the IP address of more described device and described second party;
First memory cell is stored the first key agreement information.
First packet sending unit can further send the RTCP message that carries the information of representing the key agreement success to described second party; First state set unit is provided with in the RTCP message of the information of carrying the success of expression key agreement that described first packet sending unit sends the key agreement state for consulting done state.
Referring to Fig. 5, Fig. 5 is the key agreement device of another kind of RTP message in the embodiment of the invention, and this installs corresponding above-mentioned key agreement second party, comprising: second information generating unit, second packet sending unit, the second message receiving element and second computing unit;
The described second message receiving element receives the RTCP message of the first corresponding key agreement information of the required key algorithm of the described key of the calculating of carrying with setting in advance that the key agreement first party sends; The described first key agreement information is generated by described first party;
Described second information generating unit, the described first key agreement information of utilizing the described second message receiving element to receive generates the second key agreement information corresponding with described algorithm;
Described second packet sending unit will be carried by the RTCP message by the second key agreement information of described second information generating unit generation, and this RTCP message is sent to described first party;
Described second computing unit utilizes the described second key agreement information of described second information generating unit generation and the described first key agreement information that the described second message receiving element receives, according to the described key of described algorithm computation.
This device can further comprise: second state set unit is provided with the key agreement state in the RTCP message that described second packet sending unit sends.
This device also can further comprise: second information process unit;
Described second information generating unit further generates the 3rd key agreement information according to described algorithm;
Described second state set unit is provided with in the RTCP message carry the 3rd key agreement information that described second information generating unit generates the key agreement state for consulting initial state;
Described second packet sending unit further sends to described first party and carries the RTCP message of described the 3rd key agreement information;
Described second information process unit according to the rule that sets in advance, determines that the described first key agreement information is effective.
Described second information process unit comprises: second comparing unit and second memory cell;
Described second comparing unit, the IP address of the IP address of described device less than described first party determined in the IP address of more described device and described first party;
Described second memory cell is stored the described first key agreement information.
The described second message receiving element further receives the RTCP message that carries the information of representing the key agreement success that described first party sends; The key agreement state is for consulting done state in this RTCP message.
Second packet sending unit can further send the RTCP message that carries the information of representing the key agreement success to described first party; Second state set unit is provided with in the RTCP message of the information of carrying the success of expression key agreement that described second packet sending unit sends the key agreement state for consulting done state.
Below in conjunction with specific embodiment the technique scheme that the embodiment of the invention provided is described further.
In the embodiment of the invention, establishing the key agreement first party is user B for user A, key agreement second party.In the embodiment of the invention, can adopt state machine to realize between supervisory user A and the user B being used to encrypt the process of the key of RTP message based on the DH negotiating algorithm.Referring to Fig. 6, Fig. 6 is the flow chart of arranging key between user A and the user B in the embodiment of the invention, and this flow process can may further comprise the steps:
Step 601, user A reach the standard grade, and state machine enters the Init state, produce the first key agreement information.User A sends the RTCP message to user B, in the indicated APP message of this RTCP message, carries the first key agreement information, user A side starts timer, if before timer expiry, user A does not receive the response that user B returns, and then triggers user A and retransmits this RTCP message to user B.
In this step 601, the DH algorithmic formula is: P=k
iModj.
User A produces random number k=a, i=X, j=n, and calculates P
A=a
XMod n, the first key agreement information comprises: a, X, n and P
A
In the Application-dependent data field of APP message, the type field value is " 1 "; The state field value is " 1 ", and initial state is consulted in expression; In the Data field, the Type value of a is 1, and the Type value of n is 2; P
AThe Type value be 3.
In the practical application, the value of a and n can preestablish, and all generates at random when not needing to consult at every turn.
Step 601 ', user B reaches the standard grade, the state machine of user B side enters the negotiation initial state, produce the 3rd key agreement information, and the RTCP message that will carry the 3rd key agreement information sends to user A, and in this RTCP message the key agreement state of institute's mark for consulting initial state.User's b-side boot timer, if before timer expiry, user B does not receive the response that user A returns, and then triggers user B and retransmits this RTCP message to user A.
This step 601 ' in, after user B reaches the standard grade, also can produce random number k, i and j, and calculate P=k based on the random number that is produced
iModj.
In the above-mentioned steps 601 ', if user B is before carrying the RTCP message of the 3rd key agreement information to user A transmission, received the RTCP message that carries the first key agreement information that user A sends, then will can not send for again user A and carry the RTCP message of the 3rd key agreement information.
After step 602, user A receive the RTCP message that carries the 3rd key agreement information of user B transmission, key agreement state according to institute's mark in this RTCP message is the negotiation initial state, relatively the size of the IP address of user A and user B is the first key agreement information or the 3rd key agreement information with definite effective key agreement information.
In the embodiment of the invention, establish the IP address of the IP address of user A greater than user B, correspondingly, user B determines to keep the first key agreement information, and abandons the 3rd key agreement information according to the selective rule that the embodiment of the invention adopted.
Step 602 ', after user B receives the RTCP message that carries the first key agreement information that user A sends, key agreement state according to institute's mark in this RTCP message is the negotiation initial state, the size that compares the IP address of user A and user B is to determine that keeping the first key agreement information still is the 3rd key agreement information.
In the embodiment of the invention, establish the IP address of the IP address of user A greater than user B, correspondingly, user B determines to keep the first key agreement information, and abandons the 3rd key agreement information that self generates according to the selective rule that the embodiment of the invention adopted.
Above-mentioned steps 602 and step 602 ' between do not have strict execution order, as can being to carry out side by side.
Step 603, user B utilize the first key agreement information, generate the second key agreement information.As to receiving the response of the RTCP message that carries the first key agreement information, user B sends to user A and carries the RTCP message of the second key agreement information, and the state machine of user B side enters the affirmation state of consulting.
In this step 603, user B generates i=Y based on the DH algorithm, and according to a that receives and n, calculates P
B=a
YMod n, the second key agreement information comprises: P
BIn the RTCP message that carries the second key agreement information that user B sends, in the APP message of this RTCP message indication, the state field value is set to 2, and indication consults to enter the affirmation state of consulting.
After step 604, user A received the RTCP message that carries the second key agreement information of user B transmission, state machine entered the affirmation state of consulting.
Step 605, user A computation key send the RTCP message that carries the success of expression key agreement to user B.
In this step 605, user A is further based on the P that receives
B, calculate P=P
B XMod n, wherein, P
B=a
YMod n, therefore, user A calculates P=a
Y+XMod n.
In this step 605, carry in the RTCP message of expression key agreement success, the state field value is 3, and the expression key agreement finishes.
Step 605 ', user B computation key, send the RTCP message carry the success of expression key agreement to user A.
This step 605 ' in, user B is further based on the P that receives
A, calculate P=P
A YMod n, wherein, P
A=a
XMod n, therefore, user B calculates P=a
X+YMod n, the P that calculates with user A equates.
This step 605 ' in, to carry in the RTCP message of expression key agreement success, the state field value is 3, the expression key agreement finishes.
Above-mentioned steps 605 and step 605 ' between do not have strict execution order, as can being to carry out side by side.
Above-mentioned user A is identical with the key that user B calculates respectively, i.e. P
B XMod n=P
A YMod n, thus user A and user B negotiate shared key based on the RTCP message, and this flow process can finish.
Follow-up, user A or user B can utilize and share secret key encryption RTP message, will send to the other side through the RTP message of encrypting, and guarantee the fail safe of RTP message transmissions.
In sum, in the technical scheme that the embodiment of the invention provides, utilize the RTCP message between key agreement first party and the second party, the needed key agreement information of key agreement is carried to the other side, realize the key agreement between key agreement one side and the second party.In the embodiment of the invention, owing to can carry out alternately based on RTCP between key agreement one side and the second party, with arranging key, and because the existing communication system can support RTCP usually, most communication equipments in the communication system can be supported RTCP, therefore, the technical scheme that the embodiment of the invention provides is because of needing to transform existing network, and has the prospect that can access extensive support.And, in the technical scheme that the embodiment of the invention provides, consult symmetric key between key agreement one side and the second party, the just key agreement information of between key agreement one side and second party, transmitting, and be not key, therefore, can guarantee the fail safe of key.
Further, based on the technical scheme that the embodiment of the invention provides, key agreement one side and second party are after calculating key, both sides can be based on existing SRTP technology, the key that utilization consults is encrypted the RTP message that needs transmission, thereby guarantees the fail safe of RTP message transmissions.
Claims (21)
1. the key of a RTP message is determined method, it is characterized in that, described key is used for the message encryption that sends or is used for the message that receives is deciphered, and this method comprises:
Described first party generates the first key agreement information, and the RTCP message that carries the described first key agreement information is sent to described second party; The required key algorithm of the described first key agreement information and the described key of the calculating that sets in advance is corresponding;
Described first party receives the RTCP message that carries the second key agreement information corresponding with described algorithm that described second party sends; The described second key agreement information utilizes the described first key agreement information to generate by described second party;
Described first party is utilized described first key agreement information and the described second key agreement information, according to the described key of described algorithm computation.
2. method according to claim 1 is characterized in that, in the described RTCP message that carries the described first key agreement information, it is the key agreement message that the type of message mark is indicated this message.
3. method according to claim 1 is characterized in that, the RTCP message that carries the described first key agreement information is sent to described second party comprise:
The key agreement state that is provided with in this RTCP message is the negotiation initial state.
4. method according to claim 3 is characterized in that, the RTCP message that described first party will be carried the described first key agreement information sends to after the described second party, and this method further comprises:
Described first party receives the RTCP message of the 3rd key agreement information of the described second party generation of carrying of described second party transmission, and the key agreement state in this RTCP message is for consulting initial state;
Described first party receives before the RTCP message that carries the second key agreement information corresponding with described algorithm of described second party transmission, and this method further comprises:
Described first party is determined that the described first key agreement information is effective, and is kept the described first key agreement information according to the rule that sets in advance, abandons described the 3rd key agreement information.
5. method according to claim 4 is characterized in that, described rule comprises: the key agreement information that the bigger side in IP address is generated is effective;
Described first party determines that according to the rule that sets in advance the described first key agreement information effectively comprises:
The IP address of the IP address of described first party greater than described second party determined in the IP address of more described first party of described first party and described second party.
6. method according to claim 4 is characterized in that, described rule comprises: it is effective to arrange described first negotiation information.
7. method according to claim 3 is characterized in that, in the described RTCP message that carries the second key agreement information, the key agreement state is for consulting the affirmation state.
8. method according to claim 1 is characterized in that, calculate described key after, this method further comprises:
Send the RTCP message of the information of carrying the success of expression key agreement to described second party.
9. method according to claim 8 is characterized in that, the RTCP message that sends the information of carrying the success of expression key agreement to described second party comprises:
The key agreement state that is provided with in this RTCP message is the negotiation done state.
10. according to each described method in the claim 1 to 9, it is characterized in that described RTCP message is that RTCP uses the APP message.
11. according to each described method in the claim 1 to 9, it is characterized in that, calculate described key after, this method further comprises:
Utilize the described RTP message of described secret key encryption, described RTP message is sent to described second party.
12. the key of a RTP message is determined device, it is characterized in that, comprising: first information generation unit, first packet sending unit, the first message receiving element and first computing unit;
Described first information generation unit generates the key algorithm corresponding first key agreement information required with the described key of the calculating that sets in advance;
Described first packet sending unit will be carried by the RTCP message by the first key agreement information of described first information generation unit generation, and this RTCP message is sent to the key agreement second party;
The described first message receiving element receives the RTCP message that carries the second key agreement information corresponding with described algorithm that described second party sends; The described second key agreement information utilizes the described first key agreement information to generate by described second party;
Described first computing unit utilizes the described first key agreement information of described first information generation unit generation and the described second key agreement information that the described first message receiving element receives, according to the described key of described algorithm computation.
13. device according to claim 12 is characterized in that, this device further comprises: first state set unit is provided with the key agreement state in the RTCP message that described first packet sending unit sends.
14. device according to claim 13 is characterized in that, this device further comprises: first information processing unit;
Described first state set unit is provided with in the RTCP message that carries the first key agreement information that described first packet sending unit sends the key agreement state for consulting initial state;
The described first message receiving element, the RTCP message that carries the 3rd key agreement information that described second party generates that receives further that described second party sends, and the key agreement state in this RTCP message is for consulting initial state;
Described first information processing unit according to the rule that sets in advance, determines that the described first key agreement information is effective.
15. device according to claim 14 is characterized in that, described first information processing unit comprises: first comparing unit and first memory cell;
Described first comparing unit, the IP address of the IP address of described device greater than described second party determined in the IP address of more described device and described second party;
Described first memory cell is stored the described first key agreement information.
16. device according to claim 13 is characterized in that, described first packet sending unit further sends the RTCP message that carries the information of representing the key agreement success to described second party;
Described first state set unit is provided with in the RTCP message of the information of carrying the success of expression key agreement that described first packet sending unit sends the key agreement state for consulting done state.
17. the key of a RTP message is determined device, it is characterized in that, comprising: second information generating unit, second packet sending unit, the second message receiving element and second computing unit;
The described second message receiving element receives the RTCP message of the first corresponding key agreement information of the required key algorithm of the described key of the calculating of carrying with setting in advance that the key agreement first party sends; The described first key agreement information is generated by described first party;
Described second information generating unit, the described first key agreement information of utilizing the described second message receiving element to receive generates the second key agreement information corresponding with described algorithm;
Described second packet sending unit will be carried by the RTCP message by the second key agreement information of described second information generating unit generation, and this RTCP message is sent to described first party;
Described second computing unit utilizes the described second key agreement information of described second information generating unit generation and the described first key agreement information that the described second message receiving element receives, according to the described key of described algorithm computation.
18. device according to claim 17 is characterized in that, this device further comprises: second state set unit is provided with the key agreement state in the RTCP message that described second packet sending unit sends.
19. device according to claim 18 is characterized in that, this device further comprises: second information process unit;
Described second information generating unit before not receiving the described first key agreement information, generates the 3rd key agreement information according to described algorithm;
Described second state set unit is provided with in the RTCP message carry the 3rd key agreement information that described second information generating unit generates the key agreement state for consulting initial state;
Described second packet sending unit further sends to described first party and carries the RTCP message of described the 3rd key agreement information;
Described second information process unit according to the rule that sets in advance, determines that the described first key agreement information is effective.
20. device according to claim 19 is characterized in that, described second information process unit comprises: second comparing unit and second memory cell;
Described second comparing unit, the IP address of the IP address of described device less than described first party determined in the IP address of more described device and described first party;
Described second memory cell is stored the described first key agreement information.
21. device according to claim 17 is characterized in that, the described second message receiving element further receives the RTCP message that carries the information of representing the key agreement success that described first party sends; The key agreement state is for consulting done state in this RTCP message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007101953902A CN101183935A (en) | 2007-12-17 | 2007-12-17 | Cipher key negotiation method, device and system of RTP packet |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007101953902A CN101183935A (en) | 2007-12-17 | 2007-12-17 | Cipher key negotiation method, device and system of RTP packet |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101183935A true CN101183935A (en) | 2008-05-21 |
Family
ID=39449033
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2007101953902A Pending CN101183935A (en) | 2007-12-17 | 2007-12-17 | Cipher key negotiation method, device and system of RTP packet |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101183935A (en) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012174843A1 (en) * | 2011-06-22 | 2012-12-27 | 中兴通讯股份有限公司 | Key negotiation method and system for achieving end-to-end security |
| CN103532720A (en) * | 2013-10-22 | 2014-01-22 | 杭州华三通信技术有限公司 | Transmission method and equipment of CAPWAP message |
| WO2015062239A1 (en) * | 2013-11-04 | 2015-05-07 | 华为技术有限公司 | Method and device for key negotiation processing |
| CN105704101A (en) * | 2014-11-27 | 2016-06-22 | 华为技术有限公司 | Method and equipment used for pushing message |
| CN106101081A (en) * | 2016-05-31 | 2016-11-09 | 宇龙计算机通信科技(深圳)有限公司 | Speech ciphering method, device, terminal, key management platform and system |
| WO2017045407A1 (en) * | 2015-09-17 | 2017-03-23 | 中兴通讯股份有限公司 | Method of implementing end-to-end conversation encryption, terminal and network element of network side |
| CN107079290A (en) * | 2015-08-27 | 2017-08-18 | 华为技术有限公司 | A kind of encryption call method and terminal |
| CN107846567A (en) * | 2017-11-02 | 2018-03-27 | 苏州科达科技股份有限公司 | A kind of SRTP capability negotiations method and conference terminal |
| CN109688135A (en) * | 2018-12-27 | 2019-04-26 | 东软集团股份有限公司 | Data transmission method, Vehicle Controller and the readable storage medium storing program for executing of Vehicle Controller |
| CN110719161A (en) * | 2018-07-13 | 2020-01-21 | 杭州海康威视数字技术股份有限公司 | Security parameter interaction method, device, equipment and system |
| CN113542209A (en) * | 2020-03-30 | 2021-10-22 | 腾讯美国有限责任公司 | Method, apparatus and readable storage medium for video signaling |
| CN113542209B (en) * | 2020-03-30 | 2024-06-07 | 腾讯美国有限责任公司 | Method, apparatus and readable storage medium for video signaling |
-
2007
- 2007-12-17 CN CNA2007101953902A patent/CN101183935A/en active Pending
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012174843A1 (en) * | 2011-06-22 | 2012-12-27 | 中兴通讯股份有限公司 | Key negotiation method and system for achieving end-to-end security |
| CN103532720A (en) * | 2013-10-22 | 2014-01-22 | 杭州华三通信技术有限公司 | Transmission method and equipment of CAPWAP message |
| WO2015062239A1 (en) * | 2013-11-04 | 2015-05-07 | 华为技术有限公司 | Method and device for key negotiation processing |
| CN104618103A (en) * | 2013-11-04 | 2015-05-13 | 华为技术有限公司 | Key agreement processing method and device |
| US10320917B2 (en) | 2013-11-04 | 2019-06-11 | Huawei Technologies Co., Ltd. | Key negotiation processing method and apparatus |
| CN104618103B (en) * | 2013-11-04 | 2018-05-29 | 华为技术有限公司 | Cipher key agreement processes method and apparatus |
| CN105704101B (en) * | 2014-11-27 | 2019-10-18 | 华为技术有限公司 | A kind of method and apparatus for PUSH message |
| CN105704101A (en) * | 2014-11-27 | 2016-06-22 | 华为技术有限公司 | Method and equipment used for pushing message |
| US10972438B2 (en) | 2015-08-27 | 2021-04-06 | Huawei Technologies Co., Ltd. | Method for encrypted call and terminal |
| CN107079290A (en) * | 2015-08-27 | 2017-08-18 | 华为技术有限公司 | A kind of encryption call method and terminal |
| CN107079290B (en) * | 2015-08-27 | 2020-01-10 | 华为技术有限公司 | Encrypted call method and terminal |
| CN106549906A (en) * | 2015-09-17 | 2017-03-29 | 中兴通讯股份有限公司 | Realize method, terminal and the network side element of end-to-end call encryption |
| WO2017045407A1 (en) * | 2015-09-17 | 2017-03-23 | 中兴通讯股份有限公司 | Method of implementing end-to-end conversation encryption, terminal and network element of network side |
| CN106101081A (en) * | 2016-05-31 | 2016-11-09 | 宇龙计算机通信科技(深圳)有限公司 | Speech ciphering method, device, terminal, key management platform and system |
| CN107846567B (en) * | 2017-11-02 | 2020-12-29 | 苏州科达科技股份有限公司 | SRTP capability negotiation method and conference terminal |
| CN107846567A (en) * | 2017-11-02 | 2018-03-27 | 苏州科达科技股份有限公司 | A kind of SRTP capability negotiations method and conference terminal |
| CN110719161A (en) * | 2018-07-13 | 2020-01-21 | 杭州海康威视数字技术股份有限公司 | Security parameter interaction method, device, equipment and system |
| CN109688135A (en) * | 2018-12-27 | 2019-04-26 | 东软集团股份有限公司 | Data transmission method, Vehicle Controller and the readable storage medium storing program for executing of Vehicle Controller |
| CN113542209A (en) * | 2020-03-30 | 2021-10-22 | 腾讯美国有限责任公司 | Method, apparatus and readable storage medium for video signaling |
| CN113542209B (en) * | 2020-03-30 | 2024-06-07 | 腾讯美国有限责任公司 | Method, apparatus and readable storage medium for video signaling |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101183935A (en) | Cipher key negotiation method, device and system of RTP packet | |
| CN112398651B (en) | Quantum secret communication method and device, electronic equipment and storage medium | |
| EP2426852B1 (en) | Method and system for implementing secure forking calling session in ip multi-media subsystem | |
| US9929863B2 (en) | System and method for efficient and semantically secure symmetric encryption over channels with limited bandwidth | |
| CN101908959B (en) | Method, equipment and system thereof for establishing shared key | |
| CN102281261A (en) | Data transmission method, system and apparatus | |
| CN101442403B (en) | Self-adapting method for exchanging composite cipher key and managing session cipher key | |
| US9866383B2 (en) | Key management for privacy-ensured conferencing | |
| CN104683304A (en) | Processing method, equipment and system of secure communication service | |
| CN113242122B (en) | Encryption method based on DH and RSA encryption algorithm | |
| CN101707767B (en) | Data transmission method and devices | |
| CN101958907A (en) | Method, system and device for transmitting key | |
| CN106936788A (en) | A kind of cryptographic key distribution method suitable for VOIP voice encryptions | |
| KR20210032094A (en) | Method, apparatus and system for quantum cryptography key distribution | |
| CN111478911A (en) | Instant messaging encryption method adopting lightweight key exchange algorithm | |
| CN110249584B (en) | Method for providing end-to-end security in mission critical data communication systems | |
| KR101351110B1 (en) | Apparatus and method of transmitting/receiving encrypted data in a communication system | |
| CN114500064B (en) | Communication security verification method and device, storage medium and electronic equipment | |
| KR101704540B1 (en) | A method of managing group keys for sharing data between multiple devices in M2M environment | |
| CN109889763B (en) | Call establishment method, device and storage medium of conference television system | |
| CN112217862A (en) | Data communication method, device, terminal equipment and storage medium | |
| CN106656493A (en) | Software-defined network security communication method based on quantum key distribution | |
| CN101729536A (en) | Method and system for transmitting delayed media information of IP multimedia subsystem | |
| CN107395552A (en) | A kind of data transmission method and device | |
| WO2018126783A1 (en) | Key transmission method, device, and computer storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Open date: 20080521 |