CN103974241A - Voice end-to-end encryption method aiming at mobile terminal with Android system - Google Patents

Abstract

The invention provides an Android system-oriented voice end-to-end encryption method named ERTP. When the user selects the encryption mode for communication, the two parties complete identity authentication and key negotiation at the initial stage of the session. When the call is established, both parties use their own private key and the negotiated session key to perform DSA signature on the sent RTP packet carrying voice, then encrypt it with AES algorithm, and finally send it. For the received RTP packet, first use AES to decrypt it, then perform DSA signature verification, and then process the RTP packet after the verification is passed. At this time, if a third party monitors the session, the encrypted content cannot be heard, which effectively prevents third party attacks. The invention ensures end-to-end voice communication security by adopting a one-time pad voice end-to-end encryption method.

Description

A voice end-to-end encryption method for Android system mobile terminals

technical field

The present invention is an end-to-end encryption method for mobile terminal voice based on encrypted RTP (Real-time Transport Protocol, real-time transport protocol), named as ERTP (Encrypted Real-time Transport Protocol, encrypted real-time transport protocol). The invention belongs to the field of information security.

Background technique

As the mobile terminal of the Android operating system is favored by more and more people, its security has also attracted people's attention. Especially in VoIP (Voice over Internet Protocol, Internet telephony) telephone communication, some lawbreakers take advantage of security loopholes to eavesdrop or even tamper with other people's call content through illegal means, infringe on other people's privacy and interests, and disrupt social order. A document released by the United States Patent and Trademark Office shows that Microsoft applied for a VoIP interception technology patent in December 2009, which can secretly record voice and video calls between two or more parties. Microsoft said in the application that this technology can meet the needs of government and judicial departments to eavesdrop on Internet voice calls. It applies not only to closed networks, but also to services including "Skype and similar applications." The patent application shows that the "recording client" of this technology can be embedded in various devices, including routers and so on. In addition, it can be triggered by "events" or "sequences of events", such as eavesdropping after a specific caller joins.

At present, there are mainly two methods for encrypting voice data: one is to use hardware equipment for encryption, and the other is to implement encryption by software.

The invention using hardware device encryption technology application number 200710136782.1 provides a client/server type distributed system. The SIP interface of the server device receives the SIP call connection message from the client device. When it is recognized that the client device adopts an encryption method, and When the key format can be determined, encryption is performed between communication client devices using end-to-end encryption. The encryption method of the invention is vulnerable to brute force cracking due to the limited key space. In addition, the method needs to be deployed on the server, the communication client, and the console, and the required cost is high.

Using hardware to implement encryption The invention with application number 200710195390.2 provides a key negotiation method for RTP messages in real time, using RTCP messages to negotiate keys for encrypting RTP messages. This method negotiates the key after the call starts, so the key negotiation is completed 2.5 seconds after the start of the call, the security is not strong, and it is easy to be monitored. The negotiation method is D-H exchange without identity authentication, which is extremely vulnerable to man-in-the-middle attacks.

Utilize software to implement encryption technology application number is 200810068567.7 invention, the voice data frame to be sent will be periodically transmitted to the encryption module, and the encryption module will encrypt the received voice data frame, send the encrypted voice data, and decrypt it The module decrypts the received voice data and plays it. The invention proposes an encryption and decryption method for the CDMA network, which only encrypts voice data frames without identity verification, and is vulnerable to third-party attacks. Moreover, the invention does not specify a specific encryption method, and does not carry out key agreement, that is, the key is fixed. Such encryption is extremely vulnerable to brute force cracking and is not safe.

The paper "Research and Application of Elliptic Curve Cryptography and SHA-1 Algorithm in VOIP Voice Encryption" expounds a method. The sound data is calculated according to the formula D0=d*k*P to obtain D0, and the hash is generated through continuous SHA-1 operation. Xi verifies the data, then synthesizes it with the sound data, and then sends the data through the UDP protocol. After the receiving end receives the data, it must first calculate the D0 value according to the pre-agreed elliptic curve parameters, then perform the corresponding SHA-1 calculation according to the information header of the data, and finally decompose the data to obtain the compressed sound data. However, this method does not propose a specific implementation method and process of key agreement, and has not been patented.

Contents of the invention

The purpose of the present invention is to solve the security problem of prior art, carry out safe VoIP (Voice over Internet Protocol) session through the mobile terminal based on Android system, make before RTP path is established, promptly SIP (Session Initiation Protocol, session initial protocol) session The negotiation part conducts key negotiation and identity authentication between the two parties in the call, and based on the ERTP protocol, realizes the end-to-end encryption function of the call voice data to achieve the purpose of communication confidentiality.

The principle of the present invention is: by improving the SIP media stack, and combining the SIP protocol to complete the D-H (Diffie-Hellman) key exchange protocol including the DSA digital signature, negotiate the session key and perform identity authentication on both parties of the session, so that One pad at a time and resistant to man-in-the-middle attacks. The conversation part uses the AES (Advanced Encryption Standard) algorithm with a 128-bit key to encrypt the voice data. When the calling user uses the encrypted session mode to call the called party, the called party is prompted to communicate in the encrypted mode. If the called party also adopts the encrypted mode, key negotiation will be performed; if the called party refuses the encrypted session mode, a dialog box will pop up to prompt the calling party that the session is not encrypted, and hang up the phone.

After the called party accepts the session invitation, the call is established, and the voice data of both parties is digitally signed by DSA (DigitalSignature Algorithm), encrypted with the negotiated key, and then transmitted to the other party. When the other party receives the data, it first decrypts it, and then performs the DSA signature verification operation.

The function realization of the present invention is completed based on the dynamic link library, and the interface operation and human-computer interaction are completed in the Java program framework layer in the Android system, and the two rely on the JNI (Java Native Interface, Java local call) module to communicate.

The Android system mobile terminal voice end-to-end encryption method proposed by the present invention comprises the following steps:

1) User registration: The calling and called users register on the server, including two steps of registration request and server authentication. After the registration is completed, the user can use the registered account to complete the communication of the SIP phone.

2) Initiate a call: The calling user initiates a call using the encrypted session mode, and initiates a session invitation to the server. After confirming that the user has passed the authentication, the server checks the Via header field, inserts its own address if there is no problem, and forwards the Invite request to the called terminal agent indicated by the To field of the Invite message. This part of the content is realized through the communication between the Java program framework layer and the dynamic link library.

3) Key negotiation: The calling party and the called party conduct session negotiation through the SIP protocol. During the session negotiation, the two parties perform D-H exchange, negotiate the session key and authenticate the two parties in the session. The key agreement process relies on the dynamic link library to realize.

4) Session establishment: The called party accepts the call, and the key negotiation is completed, then the call is established.

5) Encrypted communication: use the negotiated public key to sign, and then use the session key to encrypt and send to the peer. Both parties use the negotiated session key and use the AES algorithm to encrypt and decrypt the session content end-to-end to prevent tampering. The encrypted voice communication process is realized by the dynamic link library.

6) Session end: The communication parties end the session, and the session key is cleared.

Key negotiation includes two parts: identity authentication and session key negotiation. Through key negotiation, the purpose of secure negotiation and calculation of the session key of this call is achieved. The method of its realization:

1) Identity authentication: Two-way authentication is adopted, and the two parties in the session use their respective IDs for authentication to ensure that the message comes from the person and has not been tampered with. When the user initiates a session as the calling user, the server will send the public key of the called user to the calling user, and send the public key of the calling user to the called user. The calling user and the called user use their own private keys to sign the information sent by DSA during the conversation.

2) Session key negotiation: Using D-H exchange, in the case of using the other party's public key to encrypt the sent content, the session key negotiation is completed through two interactions, and a random number is attached after the public key. After two interactions, the calling party replies with the random number sent by the called party, indicating that the key negotiation is completed.

The encrypted communication includes four methods of DSA digital signature, voice encryption, voice decryption and DSA signature verification, specifically implemented as:

1) DSA digital signature: For the generated voice data, use the negotiated private key to sign the voice data, and then encapsulate the voice frame together with the signature into the RTP packet. For the received speech frame, verify its signature, continue to decode if it matches, and discard it if it does not match.

2) Voice encryption: including three steps of RTP packet extraction, RTP packet encryption, and encapsulation into UDP packets. After the voice is sampled and encoded, it is encapsulated into the RTP packet in the form of a voice frame. When encrypting the voice, extract the RTP packet, and then encrypt the RTP packet. The encrypted packet is encapsulated into a UDP packet for network transmission.

3) Voice decryption: including three steps of UDP packet decapsulation, RTP packet decryption, and DSA signature verification. After the receiving end decapsulates the UDP packet, it takes out the RTP packet carrying voice data, decrypts it, and then performs DSA signature verification.

4) DSA signature verification: For the received decrypted data, the user uses the other party's public key to perform DSA signature verification. If the verification results match, continue to operate on the RTP packet; if not, discard the packet.

After adopting the above technical solution, the present invention provides a voice end-to-end encryption method for Android system mobile terminals, the method realizes the voice encryption function of the mobile terminal VoIP phone through software. After the user completes SIP registration, initiates a call, and completes key negotiation and identity authentication between the two parties before the called party answers. After the session is established, the RTP packet carrying the communication voice is first signed by its own private key DSA, and then encrypted with the negotiated key by AES before delivery. After the receiving end receives the voice packet, it decrypts and recovers the voice packet, uses the other party's public key to verify the validity of the DSA signature, and then sends it back to the buffer. Compared with the existing encryption methods, the encryption method based on ERTP packets provided by the present invention, the voice encryption algorithm is based on RTP packets, does not need to introduce additional protocol support, has the characteristics of low overhead, high portability and easy implementation. The key negotiation process can be completed while the session negotiation is performed in the signaling part. The invention does not need additional hardware support, nor does it need to adjust the server. In addition, the user interface is friendly and easy to operate.

Description of drawings:

Fig. 1 is the application scene of the present invention;

Fig. 2 is a software structural block diagram of the present invention;

Fig. 3 is the flow chart of end-to-end voice encryption and decryption of the present invention;

Fig. 4 is the flow chart of using encryption mode to initiate a call of the present invention;

Fig. 5 is a key agreement flow chart of the present invention;

Fig. 6 is the specific implementation interaction diagram of the key agreement of the present invention;

Fig. 7 is the flowchart of session establishment of the present invention;

Fig. 8 is the flow chart of voice communication of the present invention;

Fig. 9 is a calculation diagram of the DSA signature of the present invention;

Fig. 10 is the calculation diagram of AES encryption of the present invention;

Fig. 11 is the calculation diagram of AES decryption of the present invention;

Fig. 12 is the computing diagram of the DSA signature verification of the present invention;

Fig. 13 is a flow chart of call termination in the present invention.

Specific implementation

Fig. 1 shows the application scene of the present invention, and the present invention is mainly used for Android system mobile phones that can carry out SIP calls. First, the user completes server registration. After the server registration is completed, if the user needs to make an encrypted call, then go off-hook and dial, and choose to use the encrypted mode to initiate a call 102 . In the initial stage of the session, the two parties use SIP to carry out session initial negotiation, and complete the process of identity authentication 301 and session key negotiation 302 at the same time. The identity authentication 301 process uses the user ID for two-way authentication: if the identity authentication 301 is successful, the session key negotiation 302 is performed; if not successful, the identity authentication 301 failed error is returned. During session key negotiation 302, if the negotiation is unsuccessful, the call ends and an error is returned; if the negotiation is successful, the user saves their own private key X, the other party's public key Y and the current session key K _S . After the negotiation is completed, the session is established, first initialized, and then the communication parties conduct encrypted voice communication. For the sent RTP packet carrying voice data, first use my private key X to perform DSA digital signature, then use the negotiated session key K _S to perform AES encryption, and then encapsulate it into a UDP packet for transmission; for the received UDP packet , first decapsulate, use the session key K _S to decrypt, and then perform signature verification. If the verification is successful, the RTP packet is taken out; if not successful, the packet is discarded. After the session ends, the current session key is cleared 604 .

Fig. 2 shows the software structural block diagram of the present invention. The software structure of the present invention is mainly composed of three parts: a Java program framework, a JNI module and a dynamic link library.

1) The Java program framework is a program framework developed for the Android operating system, including nine parts: UI interface, Utility device, API interface, Service service, DB database, SIP protocol stack, Widget appearance, Model model and Wizard. The UI interface is the operation interface design of the software of the present invention in the terminal operating system; the Utility device is used to call devices such as the dial keyboard and the handset; the API interface is used to describe the state of the media layer and configure management, etc., and the Service service management background operation and Cross-process access; DB database is used to store contacts, mobile phone information, etc.; SIP protocol stack implements dynamic link library within the Java program framework; Widget appearance provides skin management for the program; Model model operates on the database; Wizard guide is provided by the software Operation tips for users.

2) The JNI module defines a set of interfaces for mutual calls between the Java program framework and the dynamic link library when the standard Java program framework does not support the features required by the program.

3) The dynamic link library is the functional support for the Java program framework, and realizes the basic functions of the program, including the sound device library, the SIP protocol stack JNI library and the audio coding library. The sound device library is used to implement calls to hardware devices; the SIP protocol stack JNI library is used to implement the functions of the protocol stack and the mutual call and communication with the Java program framework; the audio encoding library is used to implement broadband audio encoding and decoding of VoIP softphones.

Fig. 3 shows the flow chart of the end-to-end voice encryption and decryption of the present invention. It mainly includes six steps of user registration 101, call initiation using encrypted mode 102, key negotiation 103, session establishment 104, encrypted call 105, and call end 106:

1) User registration 101: the user sends a registration request to the server. If the user information is not contained in the database, the query information is returned. After prompting the user to enter his ID and password, the terminal sends this message to the server. After verifying its legitimacy, the server writes the user information into the database.

2) Initiate a call using encryption mode 102: After the calling user completes the registration, choose to use the encryption mode to initiate a call to the called user; otherwise, use the normal mode to initiate a call. The human-computer interaction is completed in the Java program framework layer of the Android system, and then the obtained results are transferred to the dynamic link library through the JNI module.

3) Key negotiation 103: the two parties use the SIP protocol to perform session initial negotiation and at the same time perform identity authentication 301 and session key negotiation 302. If the identity authentication 301 is successful, the session key negotiation 302 is performed; if not successful, the identity authentication 301 failure error is returned. If the session key negotiation 302 is unsuccessful, the call ends and an error is returned. If the session key negotiation 302 is successful, the session is established 104 . This part is implemented in the dynamic link library.

4) Session establishment 104: After receiving the session confirmation message, the terminal stores the current session key 401 . After initializing 402 the buffer, initializing 403 parameters and timers, and starting the sound device 404, session establishment 104 is completed.

5) Encrypted call 105: After the call connection is established, both communicating parties use their own private keys to sign the RTP packet carrying voice data, and then use the negotiated session key to encrypt the RTP packet and the signature. After receiving the data packet, the other party first decrypts the encrypted data packet, and then compares whether the sent RTP packet is consistent with the signature. If consistent, the RTP packet is taken out for further operation. This step implements the function in the dynamic link library.

6) The call ends 106: one of the communication parties hangs up the phone, the call is released 603, and the current session key is cleared 604.

Figure 4 shows the flow chart of initiating a call using encryption mode, and its main steps are as follows:

1) The user dials 201: the user initiates a call as the calling party.

2) Select call mode 202: When initiating a call, the user first selects the mode: encryption mode or non-encryption mode, and completes the interaction between the user and the terminal at the application framework layer of the Android system. Then the obtained result is passed to the dynamic link library through the JNI module.

3) Encryption mode initialization 203: the terminal invokes the dynamic link library to determine whether to use the encryption mode. If it is the encryption mode, then carry out the encryption mode initialization, set the encryption state to 1, and prompt the called party to adopt the encryption mode communication 204; if the normal mode is selected, the encryption state is set to 0, then carry out the normal mode initialization, and the user performs normal voice calls.

4) Prompt the called party to communicate in encrypted mode 204: If the called party agrees to use the encrypted mode, the two parties will negotiate a key; if they do not agree to use the encrypted mode, a dialog box will pop up to remind the calling party that the session is not encrypted. Then the call is hung up. The encryption mode judgment of the called user is completed in the Java program framework layer, and then the result is also passed to the dynamic link library through the JNI module for configuration and calling; the calling user prompts: this call is not encrypted, and the dynamic link library will The status is uploaded to the JNI module, and then a prompt is given on the interface.

FIG. 5 shows a flowchart of the key agreement 103 . First, both parties in the session perform two-way identity authentication 301. If the identity authentication 301 is unsuccessful, the call ends and an error is returned: identity authentication 301 failed. If the identity authentication 301 is successful, both parties in the session perform key negotiation 302 . If the negotiation is unsuccessful, the call ends and an error is returned: the session key negotiation 302 fails; if the session key negotiation 302 succeeds, the session is established 104 . The content of this step is implemented in the dynamic link library.

Figure 6 shows the specific implementation interaction diagram of key agreement, including the following steps:

1) User A initiates a call, takes random number X _A as his private key, and calculates the public key , where p is a public prime number with length between 512 and 1024, and α is its primitive root. A sends an Invite request to the called party B, and at the same time sends the AES-encrypted public key Y _A , identity information ID _A and random number N ₁ with the fixed key K _fixed to the other party in the SDP (Session Description Protocol) part, That is, send Invite||E(K _fixed , Y _A ||ID _A ||N ₁ ). After receiving the confirmation that the user authentication 301 has passed, the server checks whether its address is included in the Via header field in the request: if it is included, it means that a loopback occurs, and an error response is returned; if it is not included, the server is in the requested Via The header field inserts its own address, modifies the Invite request to Invite', and forwards the message, that is, sends Invite'||E(K _fixed , Y _A ||ID _A ||N ₁ ) to user B. Then the server sends to terminal A a response message: 100Trying in call processing.

2) After receiving the forwarded message Invite'||E(K _fixed , Y _A ||ID _A ||N ₁ ), terminal B verifies whether the identity information ID _A of terminal A matches the From header field, and saves the public Key Y _A and random number N ₁ , and then send a response message in call processing to the server: 100Trying.

3) Terminal B instructs the called user to ring. After ringing, Terminal B sends a ringing message to the server: 180Ringing. The server forwards the ringing message to terminal A: 180Ringing.

4) The called user picks up the phone, terminal B takes the random number X _B as its own private key, and calculates the public key and this session key . Terminal B returns to the server a response of 200 OK indicating that the connection is successful, and includes in the SDP the public key Y _B encrypted by the fixed key K _fixed , the identity information ID _B , the random number N ₁ sent by Terminal A, and the random number N ₂ generated by itself , namely send 200OK||E(K _fixed ,Y _B ||ID _B ||N ₁ ||N ₂ ). The server forwards the success indication to terminal A.

5) After terminal A receives the message, it checks whether the identity information ID _B of terminal B matches the From header field, and checks whether N ₁ is correct. If the conditions are met, save the random number N ₂ and calculate the session key ; Otherwise return Error: Session Key Negotiation 302 Failed. Since K _S =K _S ', the session keys obtained by both parties are the same.

6) Terminal A sends the confirmation message ACK and the random number N ₂ encrypted with the fixed key K _fixed to the server, that is, sends ACK||E(K _fixed , N ₂ ). The proxy server forwards the confirmation message to terminal B. Terminal B checks the correctness of the random number _N2 : if it is correct, a communication connection is established between the calling and called users, and the call starts; if it is not correct, an error is returned: session key negotiation 302 failed.

FIG. 7 shows a flowchart of session establishment 104 . When the called party receives the session acknowledgment message ACK, the session is established, and both parties in the session store the current session key 401 , then initialize 402 the buffer, initialize 403 parameters and timers, and start the audio device 404 .

FIG. 8 shows a flowchart of voice communication 105 . The sound is first sampled into voice data after being passed through the sound device (sound device processing 501), then the data is subjected to PCM encoding (encoding/decoding 502), and the voice data is encapsulated into RTP packets (RTP packet encapsulation/decapsulation 503), and then used The private key generates a DSA digital signature for the RTP packet (DSA digital signature/signature verification 504). Afterwards, use the negotiated session key to perform AES encryption on the entire packet (RTP packet encryption/decryption 505), and then embed it into a UDP packet (UDP packet encapsulation/decapsulation 506), and finally send it. The process after receiving the UDP packet is reversed. After receiving the UDP packet, the terminal first decapsulates the UDP packet (UDP packet encapsulation/decapsulation 506), uses the session key to perform AES decryption on the encrypted RTP packet (RTP packet encryption/decryption 505), and then DSA signature verification (DSA digital signature/signature verification 504): compare the DSA digital signature generated with the plaintext and public key with the sent DSA digital signature: if they are not the same, it proves that the contents of the packet have been tampered with, and the RTP packet is discarded; The RTP packet is decapsulated (RTP packet encapsulation/decapsulation 503), the voice data is decoded (encoding/decoding 502) and then sent to the sound device, and finally played by the speaker (sound device processing 501). This part of the content is implemented in the dynamic link library.

Figure 9 shows the calculation diagram of DSA digital signature. After the terminal obtains the RTP packet rtp_pkt, select a prime number q with a length of 160 bits, and satisfy that q can be divisible by (p-1); select g to satisfy g=h ^(p-1)/q modq, where h is 1 to p An integer between -1 makes g greater than 1; generate a random number k, calculate and , wherein, the function H(rtp_pkt) generates the message hash code of the RTP packet rtp_pkt. Finally, attach the obtained DSA signature (r, s) to the RTP packet rtp_pkt, that is, generate the signed RTP packet rtp_pkt||(r, s).

Figure 10 shows the specific implementation method of RTP packet encryption. Use the negotiated 128bit session key K _S to encrypt the encapsulated RTP packet rtp_pkt and the signature (r, s) generated by the AES algorithm to obtain E{K _S ,rtp_pkt||(r,s)}. Then the encrypted ciphertext output E{K _S ,rtp_pkt||(r,s)} is embedded in the UDP packet for transmission.

Figure 11 shows the calculation diagram of RTP packet decryption. Use the negotiated 128bit session key K _S to decrypt the received encrypted RTP packets rtp_pkt' and (r', s') with the AES algorithm, that is, to E{K _S ,rtp_pkt'||(r', s')} to decrypt. Then, DSA digital signature verification is performed on the decrypted plaintext output rtp_pkt'||(r', s').

Figure 12 shows the computation graph of DSA signature verification. After decryption, take out the received RTP packet with DSA digital signature, and perform DSA signature verification. calculate , , , . test Whether v is equal to r': if it is equal, the DSA signature verification is successful, and rtp_pkt' is taken out; if not, the packet is discarded.

FIG. 13 shows a flowchart of call end 106. When the conversation between the two parties ends, one party hangs up and sends a hangup request Bye601. After the opposite end requests to reply 200 OK602, the call is released 603, and the current session key is cleared 604.

Claims (10)

1. the sound end-to-end encryption method towards Android system and mobile terminal, it is characterized in that: wrap in: comprise that user registers (101), uses that encryption mode makes a call (102), key agreement (103), session establishment (104), speech scrambling (105) and (106) six steps of end of conversation: user's registration (101) is that terminal to server is verified after its legitimacy, by user profile write into Databasce; Use encryption mode make a call (102) comprise subscriber dialing (201), select call mode (202), encryption mode initialization (203), point out called employing encryption mode communication (204) four steps, realize calling subscriber and called subscriber and carry out the selection of call mode; Key agreement (103) comprises authentication (301) and (302) two parts of session key agreement, the information that authentication (301) acknowledges receipt of is from communicating pair, and session key agreement (302) exchanges both sides' PKI and negotiates this session key; Session establishment (104) is for the initialization of the initialization of this session key and other parameters, device; Speech scrambling (105) comprises that acoustic device processing (501), coding/decoding (502), RTP seal dress/deblocking (503), digital signature/signature verification (504), RTP packet encryption/deciphering (505), UDP and seal dress/deblocking (506), ciphering process is for sent RTP bag, the method that adopts the rear AES of first DSA signature to encrypt, decrypting process, for the RTP bag receiving, adopts the method for the rear signature verification of first AES deciphering; End of conversation (106), by sending hang-up request Bye(601), 200OK(602 is replied in opposite end) after, call out and discharge (603), this session key zero clearing (604).

2. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 1, it is characterized in that: use encryption mode to make a call (102) for the java applet ccf layer based on Android system, communicate by JNI module and dynamic link library, realize parameter transmission and setting, comprise the following steps:

1) subscriber dialing (201): calling subscriber completes after registration, starts to dial;

2) select call mode (202): in the time making a call, first user carries out model selection, encryption mode or non-encrypted pattern, and whether terminal judges uses encryption mode: if encryption mode, be encrypted pattern initialization, and point out called employing encryption mode communication (204); If selection general mode, carries out general mode initialization, user carries out normal voice call; The step of model selection is mutual the java applet ccf layer completing user of Android system and terminal, subsequently the result obtaining is passed to dynamic link library by JNI module;

3) encryption mode initialization (203): terminal is called dynamic link library, judges whether to use encryption mode: if encryption mode is encrypted pattern initialization, encrypted state puts 1, and points out called employing encryption mode communication (204); If selection general mode, encrypted state sets to 0, and carries out general mode initialization, and user carries out normal voice call;

4) point out called employing encryption mode communication (204): if called agreement is used encryption mode, both sides carry out key agreement; If disagree with use encryption mode, point out session not encrypted by the mode that ejects dialog box to calling party, this call is hung up; The process of called subscriber's encryption mode judgement completes at java applet ccf layer, afterwards result is passed to dynamic link library by JNI module, is configured and calls; Calling subscriber's prompting: this call unencrypted process is to receive after the message of called refusal encryption as calling subscriber, by dynamic link library, state is uploaded to JNI module, then provides prompting at interface.

3. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 1, it is characterized in that: key agreement (103), use Session Initiation Protocol to carry out conversation initial negotiation and key agreement simultaneously, this process is carried out function realization in dynamic link library, comprises (302) two steps of authentication (301) and session key agreement:

1) in the process that conversation initial is consulted, if authentication (301) is unsuccessful, the unsuccessful mistake of end of calling return authentication; If authentication (301) success, session both sides carry out session key agreement (302); If caller is used encryption mode and called use general mode, the session key that PKI of caller is this;

2), if session key agreement (302) is unsuccessful, end of calling returns and consults failed mistake; If session key agreement (302) success, session establishment.

4. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 3, is characterized in that: authentication (301) can realize the bidirectional identity authentication between session both sides, comprises following steps:

1), when terminal A sends Invite request to terminal B, enclose and adopt fixed key K _fixedcarry out the identity message IDA of AES encryption, i.e. Invite||E (K _fixed, Y _a|| ID _a|| N ₁);

2) terminal B receives the Invite request Invite ＇ that contains identity message || E (K _fixed, Y _a|| ID _a|| N ₁) after, first with fixed key deciphering, then compare ID and whether conform to transmission header field: if conform to, continue; If be not inconsistent, return to mistake: authentication (301) failure;

3), when terminal B sends 200 OK message to terminal A, enclose and adopt fixed key K _fixedcarry out the identity message ID of AES encryption _b, i.e. 200OK||E (K _fixed, Y _b|| ID _b|| N ₁|| N ₂);

4) terminal A receives this message 200OK||E (K _fixed, Y _b|| ID _b|| N ₁|| N ₂) after, first, with fixed key deciphering, then compare ID _bwhether conform to the From header field of receiving Session Initiation Protocol: if conform to, continue; If be not inconsistent, return to mistake: authentication (301) failure.

5. according to the sound end-to-end encryption method towards Android system and mobile terminal described in claim 3 or 4, it is characterized in that: session key agreement (302) comprises following steps:

1) terminal A gets random number X _aas the private key of oneself, calculate PKI ; When terminal A sends Invite request to terminal B, enclose and adopt fixed key K _fixedcarry out the PKI Y of AES encryption _aand random number N ₁, i.e. Invite||E (K _fixed, Y _a|| ID _a|| N ₁);

2) terminal B is receiving forwarding messages Invite ＇ || E (K _fixed, Y _a|| ID _a|| N ₁), and by after authentication (301), preserve the PKI Y of terminal A _band random number N ₁;

3) called subscriber's off-hook, terminal B gets random number X _bas the private key of oneself, calculate PKI with this session key ; Terminal B returns to the 200OK that replys that represents successful connection to server, enclose and adopt fixed key K in SDP _fixedcarry out the PKI Y of AES encryption _b, terminal A send random number N ₁and the random number N oneself producing ₂, send 200OK||E (K _fixed, Y _b|| ID _b|| N ₁|| N ₂);

4) terminal A receives message, checks N ₁whether correct, if condition all meets, preserve random number N ₂, calculate this session key , K _s=K _s＇; Otherwise return to mistake: session key agreement (302) failure;

5) terminal B checks random number N ₂correctness, if correct session establishment (104) between calling and called user starts speech scrambling; Otherwise return to mistake: session key agreement (302) failure.

6. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 5, it is characterized in that: speech scrambling (105) concrete steps are: first call voice is speech data through the processing post-sampling of acoustic device, then data are carried out to pcm encoder, speech data is packaged into RTP bag, then adopts the private key of oneself to generate DSA digital signature to RTP bag; Then use the session key consulting, whole bag is carried out after AES encryption, then be embedded in UDP bag, finally send; Flow process after reception UDP bag conversely, receive after UDP bag at receiving terminal, first use session key to carry out AES deciphering to the RTP bag of encrypting, DSA digital signature and the DSA digital signature of receiving that comparison afterwards generates with plaintext and PKI: if not identical, prove that bag content is distorted, abandon this RTP and wrap and return mistake: DSA authentication failure; If identical, carry out RTP and seal the RTP bag deblocking of dress/deblocking (503), after the decoding by voice by coding/decoding (502), deliver to acoustic device, finally by playing back with loud speaker after acoustic device processing (501).

7. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 6, is characterized in that, the DSA digital signature of DSA digital signature/signature verification (504) has following step:

1) getting after RTP bag rtp_pkt, select the prime number q of 160 of length, and meet q and can divide exactly (p-1); Select g to meet g= ^(p-1)/qmodp, produces random number k, calculates with , function H (rtp_pkt) has generated the SHA-1 message hash code of RTP bag rtp_pkt;

2) the DSA signature (r, s) step 1) being calculated is attached to after RTP bag rtp_pkt, generates the RTP bag rtp_pkt|| (r, s) after signature;

3) the RTP bag rtp_pkt|| (r, s) after signature is carried out to RTP packet encryption (RTP packet encryption/deciphering 505).

8. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 7, is characterized in that: the RTP packet encryption of RTP packet encryption/deciphering (505) uses the session key K of the 128bit consulting _s, packaged RTP bag rtp_pkt and the signature (r, s) of its generation are carried out to aes algorithm encryption; Then by the ciphertext output E{K after encrypting _s, rtp_pkt|| (r, s) } and embed UDP bag, transmit.

9. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 8, is characterized in that: the RTP bag deciphering of RTP packet encryption/deciphering (505), the session key K of the 128bit that use consults _s, the encryption RTP bag rtp_pkt ＇ receiving is carried out to aes algorithm deciphering with (r ＇, s ＇), to E{K _s, rtp_pkt|| (r ＇, s ＇) } and deciphering; Then to the plaintext output rtp_pkt ＇ after deciphering || (r ＇, s ＇) carries out the DSA digital signature authentication of DSA digital signature/signature verification (504).

10. the sound end-to-end encryption method towards Android system and mobile terminal according to claim 9, is characterized in that: the DSA signature verification of DSA digital signature/signature verification (504) has following steps:

1) carrying out after the deciphering of RTP bag, taking out the RTP bag rtp_pkt ＇ of the attached DSA digital signature of receiving || (r ＇, s ＇); Calculate , , , ;

2) whether inspection v equals r ＇: if equal, show DSA signature verification success, take out RTP bag rtp_pkt ＇; If not etc., show DSA signature verification failure, abandon this RTP bag rtp_pkt ＇, and return to mistake: DSA signature verification failure.