WO2008040213A1

WO2008040213A1 - Message encryption and signature method, system and device in communication system

Info

Publication number: WO2008040213A1
Application number: PCT/CN2007/070664
Authority: WO
Inventors: Siyi Zhou; Xiaosong Lei
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-09-08
Filing date: 2007-09-10
Publication date: 2008-04-10
Also published as: CN101141251B; CN101141251A

Abstract

The invention discloses message encryption and signature method, system and device to reduce cost, burden and call-delay while the terminal is encrypting and signing. The terminal generates content key to the message to be sent, sends the generated content key to public key service device, and the public key service device encrypts the content key with public key to the entity to receive the message content; the terminal encrypts the message content only with the content key, then, sends the encrypted message and content key encrypted by the public key to opposite terminal. Before terminal encrypts message content, it sends the message content to the public key service device, the public key service signs the message content with its private key.

Description

Method, system and device for message encryption signature in communication system

[1] Technical field

[2] The present invention relates to the field of communications, and in particular to an encrypted transmission technique for information in a communication system.

[3] Background of the invention

[4] Session Initiation Protocol (Session Initiation)

Protocol, referred to as "SIP", is the core protocol in the multimedia communication system system developed by the Internet Engineering Task Force (IETF), as the next generation network (Next Generation).

The important protocol in the Network, referred to as "NGN", is mainly used to complete the multimedia session control function. The SI P protocol is currently considered to be the next generation of Internet-based Internet Protocol (Internet).

Protocol, referred to as 'ΊΡ') is one of the core protocols of the multimedia communication network, and the third generation partner project (3rd Generation Partnership)

Project, referred to as "3GPP"), has also identified the SIP protocol as the third-generation mobile communication (The Third Generation, referred to as "3G") all-IP stage multimedia domain session control protocol.

[5] Due to the security of the IP network itself and the complexity of the network, SIP signaling as a signaling for transmission over the IP network is a critical issue. The security issues of SIP signaling include ensuring the confidentiality and integrity of information, preventing replay attacks and information spoofing, providing authentication of participants in the session, and preventing Deny of Service ("DoS") attacks and applications. Security, etc.

[6] Fully encrypting the signaling will provide the best protection for the confidentiality of the signaling, and it will also ensure that the information will not be modified by malicious intermediate media. However, in practice, SIP requests and responses cannot be fully encrypted between end-to-end users, because in most network architectures, header fields (such as Request-UR I, Routes, and Via) are for the server. Must be visible, only then, SIP requests and responses can be routed correctly. Peer, the proxy server needs to modify some parameters of the message (such as increasing the Via header field value), therefore, the SIP user agent (User

The agent, referred to as "UA" for short, must release some information to the proxy server. In addition, SIP entities (such as between UA and UA) also need to identify each other. SIP itself borrows from Hypertext Transfer Protocol (Hyper Text) Transfer

Protocol, referred to as 'ΉΤΤΡ'), in terms of security, also reuses HTTP and Simple Mail Transfer Protocol (Simple Mail Transfer)

Protocol, abbreviated as "SMTP", provides a point-to-point or end-to-end security mechanism for multimedia sessions using message headers and message bodies.

[7] Several schemes for implementing security in SIP are given in IETF RFC3261:

[8] (1) Transport layer and network layer security. Two popular solutions are transport layer security (Transport Layer)

Security, referred to as "TLS" and Internet Protocol Security (internet Protocol)

Security, referred to as "IPSec").

[9] (2) SIPS URI scheme. SIPS refers to secure SIP, which follows SIP

The grammar format of the URI, but provides some measures to make the data safe to reach the specified resource. SIPS

The transport layer specified in the URI scheme must be TLS. SIPS

The URI scheme guarantees security through hop-by-hop security and a mutual trust model between servers. The SIPS URI table is not: sips:alice@ Atlanta.com;transport=tcp.

[10] (3) HTTP

Digest certification. HTTP authentication provides the ability to challenge (challenge), relying on 401 and 407 responses as well as header domain delivery challenges and credentials. The HTTP digest authentication scheme can be applied to SIP without major modifications, providing replay protection and one-way authentication. (In 3GPP, HTTP is extended to HTTP.

AKA-Digest (RFC3310), can provide two-way authentication).

[11] (4) Security / Multipurpose Internet Mail Extension (Secure/Multipurpose Internet Mail

Extensions, or "S/MIME" for short, are an end-to-end encryption. Fully encrypting SIP messages end-to-end will guarantee confidentiality, but it is impractical in practice because network intermediate media (such as proxy servers) need to read certain message header fields to ensure proper routing of messages, if these intermediate media Excluded from the security framework, SIP messages will not be routed correctly. However, SIP

The UA can encrypt the header by encrypting the message by using the S/MIMES part (such as encrypting only part of the header field and the message body), or encrypting the header field, and can provide partial header fields and message bodies. End-to-end confidentiality and integrity and mutual authentication.

Similarly, S/MIME can provide integrity and confidentiality for SIP header domains through SIP message tunneling. [12] The above HTTP

Digest authentication is based on shared key (also known as regular encryption); S/MIME is based on a public key encryption system (hereafter referred to as public key system).

[13] The coding of public key systems differs from the method of sharing keys. The public key system is asymmetric, it uses two different keys, and the symmetric shared key method uses only one key. This does not mean that public key system encryption is more secure than shared key. In fact, the security level of any encryption scheme depends on the length of the key and the computational workload involved in deciphering the password. From the perspective of combating cryptanalysis, neither conventional encryption nor the public key system is superior to the other.

[14] Similarly, public key systems do not make conventional encryption an overkill technique. Conversely, due to the huge computational credit of current public key encryption, conventional encryption will not be abandoned in the foreseeable future. . One of the inventors of public key cryptography wrote: "The almost universally accepted view is that the use of public key cryptography is limited to applications such as key management and digital signatures."

[15] In a SIP network, a network entity, such as a Proxy or Back to Back User Agent (B2B)

UA"), the information in the SIP signaling needs to be obtained, but in order to maintain security, the terminal may not want to expose all the information in the SIP signaling to all intermediate entities, and the terminal hopes to have a partial header field according to its own wishes. Information or message bodies are exposed to intermediate network entities. For example in the IP Multimedia Subsystem (IP Multimedia)

Subsystem, referred to as "IMS", in the network, the terminal wants to describe the session description protocol in the SIP message (Sessi on Description

Protocol, referred to as "SDP") Information is exposed to Proxy-Call Session Control Function ("P-CSCF") and Serving-Call Session Control (Serving-Call Session Control)

Function, abbreviated as "S-CSCF"), enables the P-CSCF to perform resource reservation and control according to the SDP. The S-CSCF can provide services according to the SDP. Similarly, the SDP information is confidential to the I-CSCF or HSS.

[16] In order to solve the above problem, the draft draft-ietf-sip-e2m-sec proposes a method for message encryption/signature, which is based on the public key system: [17] Specifically, the terminal first uses the private key of the terminal to sign different header fields or message body parts according to different requirements. After that, the terminal generates a key for encrypting the information, which is called a regular key.

(Content-Encription-Key

Referred to as "CEK"), that is, the content key, the header field or the message body is encrypted by the CEK; then the CEK is encrypted by the public key of the intermediate entity, and the key for encrypting the CEK is called key-encripti on -key, referred to as "KEK". Finally, the terminal organizes the encrypted information into S/MIME format for transmission.

[18] By this method, in the process of transmission of ciphertext, only those designated intermediate entities can decrypt and verify the digital signature, thereby ensuring the security of the information. Its network structure is shown in Figure 1.

[19] In addition, in order to reduce the public key encryption process for each message, the draft peer proposed a mechanism for regular key reuse:

[20] The terminal notifies the intermediate entity or the peer terminal through the unprotectedAttrs parameter, uses the CEK encrypted for the current message content as the KEK of the subsequent message; and generates a new CEK in each message, and the new CEK is reused by the KEK encryption. . It is worth mentioning that the KEK in this draft is a conventional encrypted key, not a public key based on the public key system. In this way, the process of public key encryption can be saved.

[21] However, since the above method requires the terminal to perform S/MIME processing and encryption, the following problems exist.

[22] 1. Because the terminal needs to be encrypted, and some use conventional encryption, and some use public key encryption, it may need to use a specific chip, resulting in an increase in the cost of the terminal;

[23] 2. Because the processing capacity of the terminal is limited, and the amount of calculation required by the public key encryption itself is large, the encryption process will increase the processing length of the terminal, which in turn leads to a delay in call connection; especially when the terminal needs to When multiple intermediate entities or peer terminals expose different information, different information needs to be encrypted or signed differently, which will lead to a sharp increase in processing delay.

[24] 3. Because the terminal needs to obtain the public key of the intermediate entity in the process of encryption, the public key can be obtained by: obtaining the public key from the specified server, or subscribing to the server (so that when the public key changes)吋 Get notified), no matter what method will increase the load on the terminal.

[25] Summary of the invention In view of the above, it is a primary object of the present invention to provide a method, system and apparatus for message cryptographic signature in a communication system such that the cost, load and call delay of the terminal for encryption and signature are reduced.

[27] In order to achieve the above object, an embodiment of the present invention provides a method for encrypting a message in a communication system, including

[28] The terminal generates a content key for the message to be sent, and sends the generated content key to the public key service device, wherein the public key service device is configured to use a public key pair of an entity that needs to know the content of the message Encrypting the content key, and returning the encrypted content key to the terminal;

[29] the terminal encrypts the content of the to-be-sent message by using the generated content key;

[30] The terminal receives the encrypted content key and transmits the encrypted message and the content key encrypted by the public key.

An embodiment of the present invention provides a method for encrypting a message in a communication system, including:

[32] The public key service device receives a content key for encrypting the message content;

[33] encrypting the content key using a public key of an entity that needs to know the content of the message;

[34] Sending the encrypted content key.

An embodiment of the present invention provides a method for message signature in a communication system, including:

[36] The terminal sends the content of the message that needs to be signed to the public key service device, where the public key service device is configured to sign the content of the message by using the first private key, and return the signed message to the Terminal

[37] The terminal receives the signed message.

An embodiment of the present invention provides a system for encrypting a message in a communication system, including:

[39] a terminal, configured to generate a content key for the message to be sent and send, and receive the encrypted content key

And encrypting the content of the message by using the generated content key, and transmitting the encrypted content key and the encrypted message;

[40] The public key service device is configured to receive the content key sent by the terminal, encrypt the content key by using a public key of an entity that needs to know the content of the message, and return the content key to the terminal.

An embodiment of the present invention provides a terminal, including:

[42] a generating module, configured to generate a content key for the message to be sent;

[43] a first encryption module, configured to encrypt content of the message by using a content key generated by the generating module [44] a first transceiver module, configured to send a content key generated by the generating module to a public key service device for encryption, receive an encrypted content key from the public key service device, and send the The encrypted content key and the encrypted message of the first encryption module.

An embodiment of the present invention provides a public key service device, including:

[46] a second transceiver module, configured to receive a content key from the terminal for encrypting the content of the message to be sent by the terminal

[47] a second encryption module, configured to encrypt, by using a public key of an entity that needs to know the content of the message, a content key received by the second transceiver module, and the encrypted content is used by the second transceiver module The key is returned to the terminal.

An embodiment of the present invention provides a system for message signature in a communication system, including:

[49] a terminal, configured to send a message content that needs to be signed to the public key service device, and receive the signed message content from the public key service device;

[50] The public key service device is configured to receive the message content from the terminal that needs to be signed, sign the content of the message by using the first private key, and send the signed message content to the terminal.

An embodiment of the present invention provides a terminal, including:

[52] The first transceiver module is configured to send the content of the message that needs to be signed to the public key service device, and receive the signed message content from the public key service device.

[54] a second transceiver module, configured to receive a message content from the terminal that needs to be signed;

[55] The signature module is configured to sign the content of the message received by the second transceiver module by using the first private key, and send the signed message content to the terminal by the second transceiver module.

[56] It can be found that the main difference between the technical solution of the present invention and the prior art is that the terminal generates a content key for the message to be sent, and sends the generated content key to the public key service device, and the public key The service device encrypts the content key by using the public key of the entity that needs to know the content of the message, and the terminal encrypts the content of the message only by using the content key, and then encrypts the encrypted message and the content key encrypted by the public key. Send to the peer terminal. By separating the public key encryption operation with a very large amount of computation from the terminal, the special public key service device performs this part of the function, so that the terminal only needs to perform some calculations. The small conventional encryption greatly reduces the burden on the terminal, and the terminal does not need to configure the special encryption and decryption chip/software of the public key system, which reduces the cost of the terminal.

[57] BRIEF DESCRIPTION OF THE DRAWINGS

[58] FIG. 1 is a schematic diagram of a network structure of message encryption in the prior art;

2 is a schematic diagram of message encryption in a communication system of the present invention;

3 is a schematic diagram of a network structure in a method of message encryption in a communication system according to a first embodiment of the present invention;

4 is a flowchart of a method for encrypting a message in a communication system according to a first embodiment of the present invention;

5 is a flowchart of a method of decrypting a message after encryption in a communication system according to a first embodiment of the present invention; [63] FIG. 6 is a system configuration diagram of message encryption in a communication system according to a third embodiment of the present invention.

[64] Mode for carrying out the invention

The present invention will be further described in detail below with reference to the accompanying drawings.

[66] In the embodiment of the present invention, the terminal generates a content key for the message to be sent, and sends the generated content key to the public key service device, and the public key service device uses the public key pair of the entity that needs to know the content of the message. The content key is encrypted, and the terminal encrypts the content of the message using only the generated content key, and then sends the encrypted message and the public key encrypted content key to the opposite terminal. By separating the public key encryption operation with a very large amount of computation from the terminal, the special public key service device performs this part of the function, so that the terminal only needs to perform some conventional encryption with a small amount of calculation, thereby reducing the burden on the terminal. Reduce the cost of the terminal for encryption.

Specifically, as shown in FIG. 2, in step 210, the terminal needs to sign the message to be sent (including the header field of the message or the specified message body), and send the content of the message to be signed to the public key service device. Then, proceeding to step 220, after receiving the content of the message, the public key service device signs the message with the first private key, and returns the signed message to the terminal. The content of the message is signed by the public key service device using the first private key, so that the terminal receiving the message can determine the source of the message, thereby combining with the subsequent encryption operation to ensure the security of the message transmission in both directions. The first private key may be a private key of the public key service device or a private key of the terminal. If the first private key is the private key of the public key service device, Since the public key service device and the terminal are in the same access domain, the public key service device can authenticate the terminal, so the signature of the public key service device of the authentication terminal can also ensure the security of the message source, and the security is adopted. Signing the private key of the public key service device ensures that the private key of the terminal is not compromised. If the first private key is the private key of the terminal, the source of the message can be uniquely determined, and the security of the source is more secure.

[69] Next, proceeding to step 230, the terminal generates a content key for the message and transmits the content key to the public key service device for encryption.

[70] Next, proceeding to step 240, after receiving the content key, the public key service device encrypts the content key by using a public key of an entity that needs to know the content of the message, and returns the encrypted content key to the content key. terminal. By separating the public key encryption operation with a very large amount of computation from the terminal, the special public key service device performs this part of the function, so that the terminal only needs to perform some conventional encryption with small calculation amount, which greatly reduces the burden on the terminal. And the terminal does not need to configure the public key system special encryption and decryption chip/software, which reduces the cost of the terminal.

[71] Next, proceeding to step 250, the terminal encrypts the signed message content using the generated content key.

[72] Next, proceeding to step 260, the terminal sends the encrypted message and the public key encrypted content key to the opposite terminal.

The first embodiment of the present invention will now be described in accordance with the principles of the invention. The first embodiment of the present invention is directed to a method of message encryption in a communication system. In this embodiment, the public key service device includes two interfaces, the first interface is the interface Y, and the second interface is the interface. As shown in FIG. 3, the interface is an interface between the public key service device and the certificate server, and the interface may be an HTTP interface or a SIP interface; the interface Z is an interface between the terminal and the public key service device, and the terminal passes through the interface Z and A secure connection is established between the public key service devices, and information is exchanged with the public key service device through the secure connection. Interface Z is based on a secure connection protocol, such as based on IPSec. For interface Z, different protocols can be used for information transfer, which can be a private interface or a SIP interface.

[74] If the interface Z uses the SIP interface, since the existing SIP protocol cannot transmit the relevant parameters, it is necessary to

The IP protocol messages are extended as follows:

[75] 1. Added first header field for requesting encryption or signature: Security-Helper

[76] This header field is used by the terminal to request encryption or signature from the public key service device, and is used to identify the terminal to the public key service. Whether the device requests to sign or request encryption. This header field contains:

[77] a. Instructing the terminal to request signature or request for encryption, represented by the method parameter in the grammar.

[78] b. Identify information in the message that requests signature or encryption. This information identifies the terminal requesting encryption/signature吋

, what is the specific content of the encryption/signature? These encrypted/signed contents are transparent to the public key service device. These information can be identified by the cid parameter and indexed to the corresponding part of the message body by the cid parameter.

[79] If the request is for encryption, the header field further contains:

[80] c. Information indicating the entity that needs to know the content of the message. The information indicates an entity that needs to know the content of the message during the transmission of the message, including an intermediate entity or a peer terminal in the message delivery path. The entities that need to know the content of the message can be one or more, and the public key information of these entities is represented by the KeyRef parameter.

[81] The first header field enables the terminal to notify the public key service device to encrypt the specified content public key by using the SIP message that extends the first header field.

[82] The extended syntax is:

[83] Security-Helper = "Security-Helper" HCOLON helper-value * (COMMA

Helper-value)

[84] helper-value = method; cid *(;KeyRef) *(SEMI generic-param)

[85] method-tag = "encrpty" I "sign" I token

[86] cid = "cid" EQUAL sip-clean-msg-id

[87] sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom I host) RDQUOT

[88] dot-atom = atom *( "." atom )

[89] atom = 1*( alphanum I "-" I "!" I " " I "*" I "_" I "+" I """ I ",,, I "-" )

[90] KeyRef = HostRef I UriRef

[91] HostRef = "hostref, EQUAL host

[92] UriRef = "uriref EQUAL absoluteURI

[93] 2. Added a second header field for returning encrypted or signed content: Security-Response

[94] This header field is used after the public key service device returns the encrypted or signed content, and is used to transfer the encrypted or signed information to the terminal by the public key service device. This header field contains: [95] a. Indicates information in the message requesting signature or encrypted content. This information corresponds to the content of the cid parameter contained in the Security-Helper header field, which is convenient for the terminal to match. The information is passed through orig-cid.

The parameters are returned to the terminal.

[96] b. Identifies the information of the signed or encrypted content in the message. Used to return the content signed or encrypted by the public key service device, indexed by the new-cid parameter.

[97] c. Information indicating the entity that needs to know the content of the message. This information corresponds to the content of the KeyRef parameter contained in the Security-Helper header field. It is also used to indicate that the entity that needs to know the content of the message during the message transmission process returns to the terminal through the same KeyRef parameter, which facilitates the terminal to complete the matching.

[98] That is to say, after the encryption is completed, the public key service device can make the terminal correctly complete the matching by mapping the cid parameter to the orig-cid parameter and returning the KeyRef as it is.

[99] The specific syntax is:

[100] Security-Response = "Security-Response" HCOLON response-value * (COMMA response-value)

[101] Response = Oirg-cid; New-cid [; KeyRef] *(SEMI generic-param)

[102] Orig-cid = "orig-cid" EQUAL sip-clean-msg-id

[103] New-cid = "new- cid" EQUAL sip-clean-msg-id

[104] The second header field enables the public key service device to return the encrypted or signed content to the terminal by extending the SIP message of the second header field.

[105] 3. Added optional tag Tag, this tag can be used in the Require header field, indicating that the public key service device must have the above Security-Helper

The header field is processed, and the public key service device is incapable of processing, and the failure indication is returned through the label.

[106] The specific syntax is: Option tag: security-helper

[107] In addition, there is no need to establish a SIP call between the terminal and the public key service device, and only SIP transaction processing is required. Therefore, the MESSAGE message can be used for communication between the terminal and the public key service device.

[108] The specific signature/encryption process is as shown in FIG. 4. In step 401, when the terminal wants the public key service device to perform security-related processing, set the Security-Helper header field according to the content of the SIP message to be signed. Set the request signature request in the method parameter of this header field, and set it in the cid parameter. The index of the message content of the line signature. After that, the terminal sends the set SIP message to the public key service device through the interface Z. The terminal may include multiple header field values in the header field, and the public key service device may separately perform signature processing on the contents indexed by the plurality of cids included in the header value fields.

[109] If the terminal cannot determine whether the server can provide the function of the public key service, you can add a tag security-helper in the Req uire header field of the SIP message, so that the server is unable to sign and encrypt and return the failure information. .

[110] Among them, the terminal can have multiple ways to discover the public key service device:

[111] 1. Configuration mode: The address of the public key service device is fixedly configured on the terminal, so that each public key sign/encryption request is sent to the corresponding public key service device;

[112] 2. Through Dynamic Host Configuration Protocol (Dynamic Host Configuration

Protocol, referred to as "DHCP" mode: When the terminal starts and obtains an IP address, the address of the public key service device of the terminal is notified through DHCP.

[113] 3. For mobile terminals, the node can be supported by the general packet radio service gateway (GPRS Gateway)

Support

Node, referred to as "GGSN", notifies the address of the public key service device of the terminal during the establishment of the packet data protocol context.

[114] Next, proceeding to step 402, after receiving the SIP message from the interface Z, the public key service device decodes and checks the message, if the Require header field in the message does not contain the security-helper tag, or contains s ecurity- The helper tag and the public key service device support the signature and encryption function, then proceeds to step 404; otherwise, if there is a security-helper in the Require header field of the message

If the public key service device does not support the signature and encryption function, then the process proceeds to step 403, and a response is sent to the terminal to inform the terminal that the public key service device does not support the signature and encryption functions.

[115] In step 404, the public key service device further checks the Security-Helper header field, first checks the method parameter in the header field, and uses the public key service after determining that the terminal is currently requesting to sign the message content. Device private key pair

The content of the cid cable is subjected to signature processing, and the signed message content is returned to the terminal through the Security-Response header field in the SIP message. If the public key service device can obtain the private key of the terminal, the content of the cid index can also be signed and processed using the private key of the terminal. If the public key service device signs The first private key used is the private key of the public key service device. Since the public key service device and the terminal are in the same access domain, the public key service device can authenticate the terminal, and therefore the public key service of the authentication terminal Signing the device also ensures the security of the source, and signing with the private key of the public key service device ensures that the private key of the terminal is not compromised. If the first private key used by the public key service device signature is the private key of the terminal, the source of the message can be uniquely determined, and the security of the source is more secure.

[116] Next, proceeding to step 405, the terminal generates a content key for the message content to be sent, and transmits the content key to the public key service device through the SIP message. Specifically, the terminal carries the content key in the SIP message body, and sets a Security-Helper header field of the SIP message, and takes the method

The parameter is set to identify the encryption request, the cid parameter is set to point to the content key, and the identifier of the intermediate entity or the peer terminal that needs to know the content of the message is set in the KeyRef parameter, and the set message containing the content key is sent to the public key service. device.

[117] Next, proceeding to step 406, after receiving the message, the public key service device also checks the method parameter in the Security-Helper header field, and after determining that the terminal currently requests encryption, checks the intermediate entity or pair indicated by the KeyRef parameter. Whether the public key of the terminal is cached locally, if not, then proceeds to step 407, and the public key service device according to the KeyRef

The parameter obtains the public key of the corresponding entity from the certificate server, and the public key service device can establish a connection with the certificate server through the interface Y, and obtain the public key of the entity that needs to know the content of the message. The process of obtaining the public key can be based on HTTP, LDAP, SIP, etc. Then proceed to step 408; otherwise, if the public key of the intermediate entity or the peer terminal indicated by the KeyRef parameter is cached locally, then the process proceeds directly to step 408.

The public key service device encrypts the content key using the public key of the entity indicated by the KeyRef parameter. In order to reduce the time consumed by the public key acquisition, the public key service device may also save the public key of the corresponding entity locally, and subscribe to the certificate update notification of the entity to the certificate server, when the public key of an entity is updated,吋Get the latest public key,

[118] Next, proceeding to step 409, the public key service device returns the encrypted content key to the terminal.

[119] Next, proceeding to step 410, the terminal encrypts the signed message content by using the generated content key thereof.

[120] Next, proceeding to step 411, the terminal sends the encrypted message and the content key encrypted by the public key to the opposite terminal. [121] In the process of encryption, in order to improve the security level of encryption, the following points should be noted:

[122] 1. The terminal and the public key service device must exchange information through a secure connection, such as IPSec.

[123] 2. The public key service device encrypts and signs the message independently of other operations in the public key service device, such as certificate acquisition/update.

[124] 3. After non-essential, the public key service device does not own the private key of the terminal. When signature is required, the public key service device uses its own private key to sign to ensure that the private key of the terminal is not compromised.

[125] 4. The message between the terminal and the public key service device prohibits the maintenance of the ordinary public key service device maintenance personnel, and sets the log record for the maintenance operation of the message. In the special case, the message can be monitored under the monitoring of the log. track. In this way, the message or key of the terminal is prevented from being leaked.

[126] 5. The public key service device prohibits the preservation of the content key of the terminal, and the public key service device should be completely stateless for the key and key reuse process.

[127] 6. The secure connection between the terminal and the public key service device is independent of the secure connection between the terminal and the SIP server. After the public key service device signs part of the message content or encrypts the content key, the content of the communication cannot be known.

[128] The following is an example of a SIP message sent by a terminal on interface Z. The font in parentheses is a description of the message and is not part of the message:

[129] In this message, the terminal requests the public key service device

[130] 1. Sign the SDP message;

[131] 2. Use the terminal for SDP

The encrypted content key is encrypted using the public key of the pizzahut.exampleB .com host.

[132] MESSAGE sip:public-key-service.exampleA.com SIP/2.0

[133] Via: SIP/2.0/UDP pc33.exampleA.com;branch=z9hG4bK776asdhds

[134] Max-Forwards: 70

[135] To: <sip:public-key-service.exampleA.com>

[136] From: Alice <sip: alice @ exampleA.com>;tag= 1928301774

[137] Call-ID: a84b4c76e66710@pc33.exampleA.com

[138] CSeq: 3 MESSAGE

[139] Contact: <sip : alice @ pc33. example A.com> Security-Helper: method=sign ;cid=''telotardmdst @ example A. com'

Security-Helper: method=encrypt;hostref=pizzahut.exampleB.com;

Content- Type: multipart/mixed;boundary="boundary- 1

Content-Length: XXX

-boundary- 1

Content- Type: application/sdp

Content- ID: <telotardmdst@exampleA.com>

V=0

o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com

s=- t=00

c=IN IP4 pc33.atlanta.com

m=audio 3456 RTP/AVP 0 1 3 99

a=rtpmap:0 PCMU/8000

Boundary-1

Content- Type: application/text

Content- ID: <atyydsdcstm@ exampleA.com>

Sdfasdfadfasdagetetetetetlteooyytmyts (here is the content key used by the terminal for encryption, but

-boundary- 1

After the public key service device signs and encrypts the corresponding content according to the request of the terminal, the message returned on the interface Z is as follows:

SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.exampleA.com;branch=z9hG4bK776asdhds

To: <sip:public-key-service.exampleA.com>

From: Alice <sip: alice @ exampleA.com>;tag= 1928301774 :166] Call-ID: a84b4c76e66710@pc33.exampleA.com

:167] CSeq: 3 MESSAGE

168] Security-Response: orig-cid=''telotardmdst@exampleA.com'';new-cid=''1234@exam pleA.com" ,

169] orig-cid="atyydsdcstm@exampleA.com";new-cid="5678@exampleA.com";

170] hostref=pizzahut.exampleB .com

171] Content- Type: multipart/mixed;boundary="boundary-l"

:172] Content-Length: XXX (fill in the actual length here)

;173] — boundaryl (Part 1, digitally signed message body)

174] Content- Type: application/pkcs7-signature; name=smime.p7s

175] Content- Transfer-Encoding: base64

176] Content-ID: < 1234 @ exampleA.com>

177] Content-Disposition: attachment; filename=smime.p7s;

178] handling=required

:179] ghyHhHUujhJ jH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6

; 180] 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJ 756tbB9HGTrfvbnj

:181] n8HHGTrfvhJ jH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

:182] 7GhIGfHfYT64VQbnj756

183] boundaryl (second 咅 |5 points, using pizzahut.exampleB.com

Public key encrypted content key)

184] Content- Type: application/pkcs7-mime; smime-type=enveloped-data;

185] name=smime.p7m

186] Content- Transfer-Encoding: base64

187] Content-Disposition: attachment; filename=smime.p7m

188] Content-ID: <5678@exampleA.com>

190] * Sdfasdfadfasdagetetetetetlteooyytmyts *

:191] [192] boundary- 1

[193] The following briefly describes the decryption method after the message is encrypted in the communication system.

[194] As shown in FIG. 5, in step 510, an intermediate entity or terminal in the message delivery path that needs to know the content of the message first uses itself after receiving the encrypted message from the terminal and the content key encrypted by the public key. The private key decrypts the content key.

[195] Next, proceeding to step 520, the intermediate entity or terminal decrypts the content of the message using the content key.

[196] After decrypting the content of the message, proceeding to step 530, the signature verification is performed using the public key corresponding to the first private key used by the public key service device to sign. If the first private key used by the public key service device signature is the private key of the public key service device, the public key of the public key service device is used to verify the content of the message, thereby determining the source of the message; if the public key service device The first private key used for the signature is the private key of the terminal, and the content of the message is verified using the public key of the terminal.

Next, a second embodiment of the present invention will be described. The second embodiment relates only to a method of message signing in a communication system. In this embodiment, after the terminal needs to sign the message content, for example, before encrypting the message to be sent, the content of the message that needs to be signed is sent to the public key service device, and the public key service device uses the first private key to The message content is signed and the signed message is returned to the terminal. The content of the message to be signed may be the message body of the SIP message or the specified header field, and the first private key used for the signature may be the private key of the public key service device or the private key of the terminal. For the case where the first private key is the private key of the public key service device, the public key service device must authenticate the terminal in advance. Since the public key service device and the terminal are in the same access domain, the authentication is achievable. In the case that the terminal is authenticated, the public key service device signs the message content for the terminal to ensure the security of the message source. Since the signature of the public key of the public key service device is used to ensure that the private key of the terminal is not compromised and security is ensured, it is ideal. Of course, if the first private key is the private key of the terminal, the source of the message can be uniquely determined, and the security of the source is more secure. It should be noted that in order to ensure that the content of the message is not leaked, the terminal and the public key service device must exchange information through an independent secure connection.

The following describes a third embodiment of the present invention. The third embodiment relates to a system for encrypting a message in a communication system. As shown in FIG. 6, the encryption system includes a terminal, a public key service device, and a certificate server. The terminal includes a generating module, configured to generate a content key for the message to be sent; Encrypting the content of the message by using the content key generated by the generating module; the first transceiver module is configured to send the content key generated by the generating module to the public key service device for encryption, and receive the encrypted content from the public key service device The content key, the encrypted content key and the encrypted message of the first encryption module are sent to an intermediate entity or a peer terminal in the message delivery path that needs to know the content of the message. The first transceiver module is further configured to send the content of the message to be sent to the public key service device for signature, and receive the signed message content returned by the public key service device; The message content encrypted by the encryption module using the content key is the signed message content.

[199] The public key service device includes: a second transceiver module, configured to receive a content key from the terminal for encrypting the content of the message to be sent by the terminal; and a second encryption module, configured to obtain a public key of an entity that needs to know the content of the message And encrypting the content key from the second transceiver module using the public key of the entity that needs to know the content of the message, and returning the encrypted content key to the terminal by the second transceiver module. The public key of the entity that needs to know the content of the message can be obtained from the certificate server or locally, and the entity that needs to know the content of the message is an intermediate entity or a peer terminal in the message delivery path.

[200] In this embodiment, the public key encryption operation with a very large amount of calculation is separated from the terminal, and then the special public key service device performs the partial functions, so that the terminal only needs to perform some conventional encryption with a small amount of calculation. The burden on the terminal is greatly reduced, and the terminal does not need to configure the special encryption and decryption chip/software of the public key system, thereby reducing the cost and burden of the terminal, since the public key service can be designed as a device with strong processing capability, thereby It can speed up the encryption process, shorten the call connection time, and further ensure the security of content key encryption. In addition, due to the public key encryption and decryption chip/software on the public key service device, statistical multiplexing can be performed among multiple terminals, so a certain convergence ratio (for example, 1000 terminals, only 100 chips) can be maintained, which can be reduced. The cost of the entire network.

[201] In order to enable the intermediate entity or the peer terminal receiving the message to determine the source of the message, to avoid the information attack of unknown source, and to ensure the security of the message transmission in both directions, the public key service device further includes: a signature module, and the terminal is in the right Before the content of the message is encrypted, the content of the message may be sent to the public key service device by the first transceiver module, and the signature module of the public key service device uses the first private key to sign the content of the message to determine the security of the message source. The first private key used for the signature may be the private key of the public key service device or the private key of the terminal. For the case where the first private key is the private key of the public key service device, the public key service device may authenticate the terminal in advance, and in the case that the terminal passes the authentication, the public key service device is the terminal. Sign the message content. It is ideal to use the private key of the public key service device to sign the peer to ensure that the security of the source is secured. Of course, if the first private key is the private key of the terminal, the source of the message can be uniquely determined, and the security of the source is more secure. It should be noted that in order to improve the security of information interaction and prevent the leakage of the terminal message content or the private key, the terminal and the public key service device must exchange information through an independent secure connection.

[202] It is worth mentioning that, in practical applications, each module in the terminal and the public key service device in the embodiment may be implemented by independent physical units, or may be combined into the same physical unit, as long as it can be implemented. The function corresponding to each module can achieve the effects of the present invention.

The fourth embodiment of the present invention will now be described. The fourth embodiment separates the message signatures in the communication system from the encryption system to form an independent signature system. The system includes a terminal and a public key service device, where the terminal includes a first transceiver module, configured to send the content of the message that needs to be signed to the public key service device, and receive the signed message content from the public key service device; The device includes a second transceiver module, configured to receive a message content from the terminal that needs to be signed, and a signature module, configured to sign, by using the first private key, the content of the message received by the second transceiver module, and the signature is performed by the second transceiver module The content of the message is sent to the terminal.

While the invention has been illustrated and described with reference to the preferred embodiments embodiments of the present invention The spirit and scope of the invention are not departed.

Claims

Claim

[1] 1. A method for encrypting a message in a communication system, comprising:

The terminal generates a content key for the message to be sent, and sends the generated content key to the public key service device, wherein the public key service device is configured to use the public key of the entity that needs to know the content of the message to encrypt the content. Key encryption, and returning the encrypted content key to the terminal; the terminal encrypts the content of the message to be sent by using the generated content key; the terminal receives the encrypted content key, and sends The encrypted message and the public key encrypted content key.

[2] The method for encrypting a message in a communication system according to claim 1, wherein the terminal obtains an address of the public key service device by one of the following methods:

Obtaining, by the terminal, an address of a locally fixed public key service device; or

Receiving an address of the public key service device notified by a dynamic host configuration protocol; or receiving, in a packet data protocol context establishment process, an address of the public key service device, wherein the terminal is a mobile terminal.

[3] The method for encrypting a message in the communication system according to claim 1, wherein the terminal further comprises: before encrypting the content of the message to be sent, the terminal further comprises:

Sending the content of the to-be-sent message to the public key service device, where the public key service device is configured to sign the content of the to-be-sent message by using the first private key, and after the signature Message back to the terminal;

The terminal encrypts the signed message content using the generated content key.

[4] The method for encrypting a message in a communication system according to claim 3, wherein the first private key comprises: a private key of the public key service device or a private key of the terminal.

[5] The method for encrypting a message in the communication system according to claim 3, wherein the message to be sent is a session initiation protocol SIP message, and the content of the message to be sent is a message of a SIP message. Body and / or specify the header field.

[6] 6. The method for encrypting a message in a communication system according to claim 5, wherein the SIP message includes a first header field for requesting encryption or signature, and the first header field includes One of the following or any combination: Instructing the terminal to request signature or request for encrypted information;

Identifying information in the message requesting to sign or encrypt content;

Information indicating the entity that needs to know the content of the message.

[7] The method for encrypting a message in a communication system according to any one of claims 1 to 6, wherein the terminal establishes a secure connection with the public key service device through the second interface, And interacting with the public key service device through the secure connection;

The second interface is based on a secure connection protocol;

The second interface is a private interface or a SIP interface.

[8] 8. A method for encrypting a message in a communication system, comprising:

The public key service device receives a content key for encrypting the message content;

Encrypting the content key using a public key of an entity that needs to know the content of the message; transmitting the encrypted content key.

[9] 9. The method for encrypting a message in a communication system according to claim 8, further comprising:

The public key service device receives the message content to be signed;

Signing the message content using the obtained first private key;

Sending the signed message content.

[10] The method for encrypting a message in a communication system according to claim 9, wherein the first private key comprises: a private key of the public key service device or a terminal that sends the message content Private key.

[11] The method for encrypting a message in a communication system according to claim 9, wherein the message received by the public key service device comprises: a first header field for requesting encryption or signature, The first header field contains one of the following or any combination thereof:

Instructing the terminal to request signature or request for encrypted information;

Identifying information in the message requesting to sign or encrypt content;

[12] 12. The method for encrypting a message in a communication system according to claim 11, wherein the message received by the public key service device further includes an optional label, and the public key service device is The ability to encrypt or sign the content in the message 返回, returning a failure indication via the optional tag.

[13] The method for encrypting a message in a communication system according to claim 8, wherein the public key of the entity that needs to know the content of the message is obtained by: the public key service device The certificate server or the public key of the entity that needs to know the content of the message is obtained locally.

[14] 14. The method for encrypting a message in a communication system according to claim 13, wherein the public key service device establishes a connection with the certificate server through the first interface, and obtains the content that needs to know the message. The public key of the entity;

The first interface is a hypertext transfer protocol interface or a SIP interface.

[15] The method for encrypting a message in a communication system according to claim 9 or 11, wherein the message received by the public key service device comprises: a second header for returning encrypted or signed content The second header field includes one of the following or any combination thereof:

Indicating information of the content requested to be signed or encrypted in the message;

Identifying information of the signed or encrypted content in the message;

[16] 16. The method for encrypting a message in a communication system according to claim 8, wherein the public key service device prohibits a general maintenance personnel from tracking messages between the public key service device and other devices, and The maintenance operation of the message sets a log record.

[17] 17. The method of message encryption in a communication system according to claim 8, wherein the public key service device prohibits saving the content key.

[18] 18. The method for encrypting a message in a communication system according to claim 8, wherein the entity that needs to know the content of the message is an intermediate entity or a peer terminal in the message delivery path.

[19] 19. A method for message signature in a communication system, comprising:

The terminal sends the message content that needs to be signed to the public key service device, where the public key service device is configured to sign the message content by using the first private key, and return the signed message to the terminal;

The terminal receives the signed message.

[20] 20. The method of message signature in a communication system according to claim 19, wherein The first private key includes: a private key of the public key service device or a private key of the terminal.

[21] The method for message signature in a communication system according to claim 19, wherein the message to be signed is a session initiation protocol SIP message, and the content of the message to be signed is

The message body of the SIP message and/or the specified header field.

[22] 22. A system for encrypting messages in a communication system, comprising:

a terminal, configured to generate a content key for the message to be sent and send, and receive the encrypted content key, and encrypt the content of the message by using the generated content key, and encrypt the encrypted content Key and the encrypted message are sent;

And a public key service device, configured to receive a content key sent by the terminal, encrypt the content key by using a public key of an entity that needs to know the content of the message, and return the content key to the terminal.

[23] 23. The system for encrypting a message in a communication system according to claim 22, further comprising a certificate server, wherein the public key service device is further configured to obtain the need to know the message from the certificate server. The public key of the entity of the content.

[24] 24. A terminal, comprising:

a generating module, configured to generate a content key for the message to be sent;

a first encryption module, configured to encrypt a content of the message by using a content key generated by the generating module;

a first transceiver module, configured to send a content key generated by the generating module to a public key service device for encryption, receive an encrypted content key from the public key service device, and send the encrypted a content key and a message encrypted by the first encryption module.

[25] 25. The terminal according to claim 24, wherein the first transceiver module is further configured to send the content of the message to be sent to the public key service device for signature, and receive the Decoding the signed message content returned by the public key service device;

The message content encrypted by the first encryption module using the content key is the signed message content.

[26] 26. A public key service device, comprising:

a second transceiver module, configured to receive a content key from the terminal for encrypting the content of the message to be sent by the terminal;

a second encryption module, configured to use the public key pair of the entity that needs to know the content of the message The content key received by the transceiver module is encrypted, and the encrypted content key is returned by the second transceiver module to the terminal.

[27] 27. The public key service device according to claim 26, further comprising a signature module

And after the second transceiver module receives the content of the to-be-sent message from the terminal, using a first private key to sign the content of the message, and signing the signed by the second transceiver module The subsequent message content is returned to the terminal.

[28] 28. A system for message signing in a communication system, comprising:

a terminal, configured to send a message content that needs to be signed to the public key service device, and receive the signed message content from the public key service device;

And a public key service device, configured to receive a message content from the terminal that needs to be signed, sign the content of the message by using a first private key, and send the signed message content to the terminal.

[29] 29. A terminal, comprising:

The first transceiver module is configured to send the content of the message that needs to be signed to the public key service device, and receive the signed message content from the public key service device.

[30] 30. A public key service device, comprising:

a second transceiver module, configured to receive a message content that needs to be signed from the terminal, and a signature module, configured to sign, by using the first private key, the content of the message received by the second transceiver module, and by the second transceiver module The signed message content is sent to the terminal.