WO2008040201A1

WO2008040201A1 - A method for obtaining ltk and a subscribe management server

Info

Publication number: WO2008040201A1
Application number: PCT/CN2007/070620
Authority: WO
Inventors: Qinwei Zhang; Ruinan Sun; Zhibin Li; Zhuo Sang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-09-05
Filing date: 2007-09-04
Publication date: 2008-04-10
Also published as: CN101141246A; CN101141246B

Abstract

A method for obtaining long term key (LTK) includes: the first subscribe management server receives the first request message carrying the service identifier; the first subscribe management server obtains the service LTK corresponding with the service identifier in said request message; creates long term key message (LTKM) according to said LTK, and sends said LTKM. Also, the present invention provides a subscribe management server. The present invention thusly enables user to obtain LTK created by a plurality of subscribe management server through one subscribe management server, reduces the unnecessary safety registration, improves the user experience.

Description

Long-term key acquisition method and a subscription management server

Technical field

The present invention relates to a mobile broadcast service, and more particularly to a long-term key acquisition method and a subscription management server. Background of the invention

Currently, there are several mainstream technologies for providing mobile video broadcasting: Multimedia Broadcast Multicast Service (MBMS), Broadcast Multicast Service (BCMCS), and Handheld Digital Television Broadcasting (DVB-H, Digital Video). Broadcast - Handset ). In order to provide a unified service platform, the Open Mobile Alliance (OMA) has proposed a new mobile multimedia architecture broadcast (BCAST, Broadcast).

In the broadcast service, in order to ensure that the subscribers can receive the program and prevent the unsigned users from watching, the service protection mechanism is crucial. Therefore, the business protection in BCAST generally uses a 4-layer protection model.

Figure 1 is a schematic diagram of the business protection model in BCAST. As shown in Figure 1, the business protection model in BCAST specifically includes the following four layers:

The first layer: the authentication layer. This layer is used for authentication between the device on the terminal side and the server on the network side. That is, the device on the terminal side and the server on the network side authenticate each other through a two-way channel or an offline mode. After the authentication is passed, the server on the network side and the device on the terminal side can obtain a shared key, and the server on the network side and the device on the terminal side respectively generate a corresponding user key according to the shared key, which is used to protect the authentication layer. information. For the 3GPP, Third Generation Partnership Project (3GPP, Third Generation Partnership Project 2) network In the smart card service protection mode, the user key mentioned above is a shared subscription management key (SMK, Subscriber Management Key) generated by smart card registration authentication; and for the digital right management (DRM) method The user key mentioned above is a rights encryption key (REK, Rights Encryption Key) generated by terminal registration authentication.

The second layer: Long-term key message (LTKM, Long Term Key Message) transport layer. This layer is used by the server on the network side to transmit a Long Term Key (LTK), that is, a service/program key, to the device on the terminal side. The service/program key includes a Service Encrypt Key (SEK) or a Program Encrypt Key (PEK). Specifically, the server-side service/program key message generating module on the network side encrypts the received service/program encryption key (ie, LTK) according to the REK or SMK of the authentication layer, and generates a long-term key message LTKM, and Sending it to the device on the terminal side; the device on the terminal side decrypts the received LTKM according to the REK or SMK of the authentication layer, and then obtains the service/program encryption key (ie, LTK) required to be transmitted by the server end. ) and use the service/program encryption key as the service/program decryption key.

The third layer: Short-term key message (STKM, Short Term Key Message) transport layer. This layer is used to transmit a Traffic Encryption Key (TEK) to the device on the terminal side. Specifically, the server-side transport key message generating module on the network side encrypts the received TEK according to the SEK or PEK of the LTKM transport layer, generates a short-term key message STKM, and sends the short-term key message STKM to the device on the terminal side; The device on the terminal side decrypts the received STKM according to the SEK or PEK of the LTKM transport layer, and obtains the TEK required to be transmitted by the server, and uses the TEK as a transport decryption key.

The fourth layer: transport encryption layer. This layer is used to transfer data (for example, broadcasted content) to devices on the terminal side. Specifically, the server-side encryption module on the network side encrypts the data to be transmitted by using the transmission encryption key TEK of the STKM transport layer, and then encrypts the encrypted data. The data is sent to the device on the terminal side; the device on the terminal side decrypts the received encrypted data according to the TEK of the STKM transport layer, and the data to be transmitted by the server end is obtained.

In OMA's BCAST service protection, two solutions were introduced, namely Smartcard Profile and Digital Rights Protection (DRM Profile).

The Smartcard Profile uses the Universal Subscriber Identity Module (USIM) card or the Removable User Identity Module (RUIM) card to store SMK, SEK, and PEK, and uses the security of the smart card to ensure the service. The security of the key. When the service protection mode of the smart card profile is adopted, the security mechanism of the MBMS and the security mechanism of the BCMCS are respectively followed.

The DRM Profile uses OMA's DRM technology, which controls the use of digital content primarily through rights restrictions and content protection schemes. Specifically, the DRM technology mainly includes a DRM terminal (DRM Agent), a digital content issuer (CI, Content Issuer), an authorized issuer (RI, Rights Issuer), a user entity, and a storage device. The basic principle of DRM technology is: After the digital content publisher encrypts the digital content, the user downloads the encrypted digital content data packet to the terminal; RI is responsible for distributing the license corresponding to the digital content, and the license is obtained by the license key. Encryption, and the license key is encrypted by the RI using the device public key. The above license includes the content decryption key and the authority to operate the content. Therefore, the device can only use the purchased digital content only if it has both the content data package (which contains the information necessary for decrypting the digital content) and the license. . Since in the DRM technology, REK, SEK and PEK are all stored in the DRM Agent, the security of the key is guaranteed by the DRM Agent. For example, in the four-layer protection model implemented based on the OMA-based DRM 2.0 standard, the copyright object (RO, Rights Object) containing the SEK and/or PEK is transmitted in the second layer. Therefore, the DRM Agent can decrypt the license key by using the private key of the device, thereby obtaining the content key in the license, decrypting the digital content, and controlling the specific use of the digital content by the user according to the permission information in the license. The broadcast service provided in BCAST requires the user to order, and the user will get the corresponding long-term key, ie SEK or PEK. Among them, SEK is provided to long-term subscribers, while PEK is provided to users of Pay-per-view. The DRM profile-based terminal sends a subscription request to the BCAST Subscription Manager (BSM, BCAST Subscription Management), that is, the subscription management server, and after BSM authentication, the BSM sends a Request Object Acquisition Protocol (ROAP) to the RI. The triggered message, the RI obtains a Service Encrypt Authentication Key (SEAK) or a Program Encrypt Authentication Key (PEAK) from the BSM, generates a corresponding RO for the terminal, and returns The ROAP triggers a response message to the BSM. The BSM sends a ROAP trigger message (including the URL address of the RI) to the terminal, and notifies the terminal to acquire the RO that has been generated by the RI. After receiving the notification, the terminal directly interacts with the RI through the DRM mechanism to obtain the corresponding RO. The DRM RI requires that the DRM Agent on the terminal must obtain the RO after the RI is registered. If the terminal DRM Agent has not been registered with the RI, the corresponding 4-step (4 pass) registration process is started before the RO is acquired.

In the broadcast service roaming, when the user wants to receive the roaming service, the BSM (which can be set as the first subscription management server) of the home service provider (SP, Service Provider) can send the request message and pass the attribution SP. The BSM authenticates the service in the BSM of the roaming SP (which can be set as the second subscription management server). After the user authenticates through the roaming service, the terminal may request a long-term key message from the BSM of the home SP through the BSM of the home SP. The BSM of the roaming SP needs terminal or smart card information to successfully generate a long-term key message for the terminal. Therefore, the terminal reports the terminal or smart card information to the BSM of the home SP, and the BSM of the home SP sends the information to the roaming place. SP's BSM. When the DRM method is used for service protection, the terminal also needs to register in advance at the RI of the roaming SP. The BSM of the roaming SP sends the generated long-term key message to the terminal through the BSM of the home SP. After receiving the long-term key message, the terminal can parse the SEK or The PEK, which is used to decrypt the TEK for the encrypted service, receives the corresponding broadcast service provided by the roaming place SP.

However, in the prior art, some broadcast television networks are one-way networks, such as DVB-H networks. When the network of the roaming area is a one-way network, the terminal cannot directly interact with the BSM of the roaming place, and it is also inconvenient to perform terminal or smart card registration authentication on the network of the roaming place, and the required broadcast service key cannot be obtained. In addition, when the terminal needs to obtain services from multiple subscription management servers, it needs to register with multiple subscription management servers separately to obtain service keys. The whole process is complicated and unsafe. In addition, in the prior art, if a plurality of broadcast SPs provide a broadcast service to a user through the same network operator, and a long-term key message is generated by the BSM of the SP, the SP needs to acquire some private information of the user (for example, a mobile phone number). After the time), a long-term key message can be generated. In this case, the security of the user information cannot be guaranteed. Summary of the invention

Embodiments of the present invention provide a long-term key acquisition method and a subscription management server, so that a user can obtain long-term keys of other subscription management servers through one subscription management server.

To achieve the above objective, the technical solution of the embodiment of the present invention is implemented as follows: A long-term key acquisition method, the method includes:

Receiving, by the first subscription management server, a first request message carrying a service identifier;

The first subscription management server acquires a long-term key of the service corresponding to the service identifier in the first request message;

And generating the long-term key message according to the long-term key generation long-term key message. An embodiment of the present invention further provides a subscription management server, where the subscription management server includes: a service subscription/key management module and a key message generation module; The service subscription/key management module is configured to receive a first request message, obtain a long-term key and/or long-term key association information of a service corresponding to the service identifier in the first request message; The key and/or long-term key association information is sent to the key message generation module;

The key message generating module is configured to generate and send a corresponding long-term key message according to the received long-term key and/or long-term key association information.

An embodiment of the present invention further provides a subscription management service system, where the subscription management service system includes: a first subscription management server and a terminal;

The first subscription management server is configured to receive a first request message that is sent by the terminal and that carries a service identifier, and obtain a long-term key of a service that is corresponding to the service identifier in the first request message; The key generates a long-term key message, and sends the long-term key message to the terminal;

The terminal is configured to send a first request message carrying a service identifier to the first subscription management server, and receive a long-term key message sent by the first subscription management server.

In the long-term key acquisition method and the subscription management server proposed by the embodiment of the present invention, since the terminal obtains the long-term key of the roaming service by subscribing to the management server, without interacting with the BSM of the roaming place, Therefore, even in the case where the network of the roaming area is a one-way network, the terminal can obtain the required long-term key.

Secondly, in the implementation of the present invention, the long-term key generated by the second subscription management server is encrypted by the first subscription management server, and the generated long-term key is not required to be encrypted by the second subscription management server, so the user is not required to be in the first The second subscription management server or the related server of the domain in which it is located is securely registered, so that the user can acquire multiple subscription management servers to generate a long-term key through a subscription management server, thereby reducing unnecessary security registration and enhancing the user experience.

In addition, in the embodiment of the present invention, the first subscription management server sends the second subscription management service to the second subscription management service. The substitute user identifier is allowed in the message of the server, and the second subscription management server can use the substitute user identifier to perform service authentication on the user, which reduces the network transmission of the actual user identifier, thereby improving user information security.

In addition, in the embodiment of the present invention, in the case of the service protection using the smart card method, the first subscription management server is used as the network application server NAF to obtain the subscription key KS_NAF from the boot server BSF, and the service key of the second subscription management server is encrypted, so that The second subscription management server can obtain the requested service key without the NAF function, which simplifies the function and complexity of the second subscription management server. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a schematic diagram of the business protection model in BCAST.

FIG. 2 is a general flowchart of a method for acquiring a long-term key in an embodiment of the present invention.

FIG. 3 is a specific flowchart of a method for acquiring a long-term key in an embodiment of the present invention. Or a flowchart of the method of key update.

FIG. 5 is a flowchart of a method for implementing an indirect broadcast service subscription or key update by using the GBA method according to an embodiment of the present invention.

FIG. 6 is a flowchart of a method for acquiring a home-initiated roaming service key according to an embodiment of the present invention.

FIG. 7 is a flowchart of a method for acquiring a broadcast service key initiated by an operator to a service provider according to an embodiment of the present invention.

FIG. 8 is a structural diagram of a subscription management server in an embodiment of the present invention.

FIG. 9 is a structural diagram of a subscription management service system according to an embodiment of the present invention. Mode for carrying out the invention

Specific embodiments of the present invention will be further described in detail below with reference to the drawings and embodiments.

For the convenience of description, in the following description, we can set the BSM of the subscription management server or the home SP of the terminal to the first subscription management server, and set the BSM of the roaming subscription management server or the roaming SP. a second subscription management server; in addition, when the service that the terminal needs to subscribe to does not need to distinguish the home location or the roaming place (for example, subscribes to the SP for the program provided by the SP through the network operator's platform), for the terminal, Network operators are generally more trustworthy and more secure than normal SPs. In addition to providing subscription management services, network operators can also contact other SPs that provide subscription management services. Therefore, network operations can also be performed. The subscriber's subscription management server is set as the first subscription management server, and the BSM of the SP is set as the second subscription management server.

FIG. 2 is a general flowchart of a method for acquiring a long-term key in an embodiment of the present invention. As shown in FIG. 2, the long-term key acquisition method in the embodiment of the present invention includes the following steps:

Step 201: The terminal sends a request message carrying the service identifier to the first subscription management server. The request message may further carry information such as a second subscription management server identifier and a user ID (such as a mobile phone SIM card number).

Step 202: The first subscription management server acquires long-term key and/or long-term key association information of the service corresponding to the service identifier in the request message. The long-term key association information is information related to the long-term key, such as the validity period of the long-term key.

Step 203: The first subscription management server generates a long-term key message according to the long-term key, and sends the long-term key message to the terminal.

In the broadcast service, the service identifier in the foregoing process may also be a purchase item identifier, that is, a service purchase item identifier that allows the user to order, or a purchase item identifier formed by combining a plurality of services. FIG. 3 is a specific flowchart of a method for acquiring a long-term key in an embodiment of the present invention. The first subscription management server may be a subscription management server of the home of the terminal, or may be a BSM of the home SP, and the second subscription management server may be a subscription management server that serves the roaming location, or may be a BSM of the roaming SP. As shown in FIG. 3, the specific process of the long-term key acquisition method in the embodiment of the present invention includes the following steps:

Step 301: The terminal sends a first broadcast service subscription request message to the first subscription management server.

In step 301, the first broadcast service subscription request message includes a second subscription management server identifier, a user identifier, a service identifier to be subscribed, or a subscription identifier. In addition, when the service identifier is globally unique or includes a second subscription management server identifier (for example, the service identifier is a subscription service server identifier concatenated with a service number), the second subscription service subscription request message may not include the second subscription management server. And the first subscription management server may infer the second subscription management server identifier from the service identifier in the first broadcast service subscription request message. In addition, the first broadcast service subscription request message may further include terminal information (Device ID) or smart card information, which is used when the first subscription management server generates a required long-term key message for the terminal in a subsequent step. The terminal information may be an International Mobile Station Equipment Identity (IMEI), and the smart card information may be a mobile phone SIM card number or the like. The user who uses the terminal can obtain the subscribed service or subscription information and determine the service to be subscribed in multiple ways. For example, the terminal can obtain the service or subscription information of the second subscription management server through the broadcast service guide SG, and display it to the user. The user is allowed to directly select the service to be subscribed through the terminal; in addition, the user can also obtain the service or subscription information through the portal (PORTAL), advertisement, and the like, and then input the service information to be subscribed through the terminal.

Step 302: The first subscription management server sends a second broadcast service subscription request to the second subscription management server. Specifically, the first subscription management server first authenticates the user in the terminal, and when the user is a legitimate user and has the right to subscribe to the service managed by the second subscription management server, the first subscription management server manages according to the second subscription. The server identifier sends a second broadcast service subscription request including a user identity (or an alternate user identity), a service identity to be subscribed, or a subscriber identity to the second subscription management server. The second subscription management server identifier may be directly obtained from the first broadcast service subscription request received by the first subscription management server; or, the second subscription management server identifier is inferred by using the service identifier in the first request message, The second subscription management server identifier may not be included in the first request message sent by the terminal to the first subscription management server.

In order to ensure that the user identifier is not analyzed by the second subscription management server to ensure the privacy of the user information, the first subscription management server may convert the user identifier into an alternate user identifier. The first subscription management server may generate an alternate user identifier, store the user identifier and the substitute user identifier, and associate the two by using a computing method or a logical method according to the user identifier. For example: The user ID is the mobile number 13812345678, and the first subscription management server uses an algorithm or other method to convert the user ID to the alternate user identification number CH0987. The second subscription management server does not know the real mobile number of the CH0987 user, but only uses the CH0987 number as the identity of the user for maintenance. If the first subscription management server sends the substitute user identifier to the second subscription management server in the second broadcast service subscription request, in the subsequent step, all the information between the first subscription management server and the second subscription management server is related to the The user's communication will all use an alternate user ID.

Step 303: The second subscription management server returns a broadcast service subscription response message to the first subscription management server.

Specifically, the second subscription management server stores the information of the user, and according to the user identifier or the substitute in the second subscription request message sent by the first subscription management server. The user identity authenticates the user service, and returns a broadcast service subscription response message to the first subscription management server, where the response message includes the user subscription service authentication result. The service authentication result may include, but is not limited to, whether the user is an illegal user, whether the user can request the service, and the like.

Step 304: The first subscription management server returns a broadcast service subscription response message to the terminal. The broadcast service subscription response message includes a user subscription service authentication result, which is used to display the service authentication result to the user, and prompts the user whether to continue to obtain the requested service or the key of the subscription item.

Step 305: The terminal returns a confirmation to receive the subscription service message to the first subscription management server. The acknowledgment receiving subscription service message includes the result of the user confirmation, and may also include the identifier of the service or subscription item that the user wants to obtain. If the user does not want to obtain the key, the entire process ends; if the user wants to obtain the key, and the first subscription request message in step 301 does not carry the terminal information or the smart card information, the acknowledgement needs to be received in the subscription service message. It includes the user's terminal information (for example, the terminal international mobile station device identification) or smart card information.

Step 306: The first subscription management server sends a request long-term key message to the second subscription management server, requesting the long-term key LTK of the service or subscription that the user wants to obtain.

The requesting long-term key message may include a service identifier or a subscriber identifier that the user confirms that the key needs to be obtained. If the user subscribes to the monthly subscription service, the long-term key is the service encryption authentication key SEAK (the service key SEK can be obtained by the SEAK); if the user only wants to use the Pay-per-view, the long-term key The program authentication key PEAK is encrypted for the program (the program key PEK can be obtained by PEAK).

Step 307: The second subscription management server determines whether the requested service or the LTK of the order item has been stored. If the LTK is stored, the second subscription management server sends the LTK to the first subscription management server; if not stored The LTK or stored The LTK needs to be updated, and the second subscription management server generates a corresponding LTK and sends the generated LTK to the first subscription management server. The LTK sent to the first subscription manager may also include LTK association information, which may include, but is not limited to, related services or purchase item identifiers, LTK validity periods or application rules, and the like.

Step 308: The first subscription management server encrypts the service or subscription item requested by the user by using the rights encryption key REK or the subscription management key SMK generated when the user securely registers with the first subscription management server according to the user terminal information or the smart card information. LTK, generates a long-term key message LTKM, and sends the generated LTKM to the terminal; or the first subscription management server uses the REK or SMK generated by the network side when the long-term key encryption of the service is required to encrypt the user request. The LTK of the business or order item, generates LTKM, and sends the generated LTKM to the terminal. The LTKM carries the LTK of the service or subscription item encrypted by the first subscription management server.

In the above steps, if the user has been allowed to subscribe to the requested service or perform key update through the service authentication of the second subscription management server, steps 303-306 may be omitted, and the second subscription management server directly passes step 307. Returns the long-term key requested by the first subscription management server user. Alternatively, steps 304 and 305 may be omitted, that is, the user confirmation process is omitted. After receiving the broadcast service subscription response message in step 303, the first subscription management server directly performs step 306, that is, according to the received broadcast service subscription response message to the second. The subscription management server sends a request long-term key message requesting the required long-term key. If the user fails to subscribe to the requested service or updates the requested service key through the service authentication of the second subscription management server, the corresponding result needs to be returned to the user through steps 303 and 304, and the entire process is ended.

In the above steps, the first subscription management server may determine whether the terminal or the smart card has been securely registered before receiving the broadcast service subscription request of the user, or before encrypting the LTK to generate the LTKM. If the terminal is not already in the first subscription management server After the security server of the domain is registered, the first subscription management server cannot be successfully generated.

LTKM.

Certainly, the first subscription management server may notify the terminal to initiate a corresponding security registration process, complete the process of the first layer authentication registration layer of the broadcast service security architecture, so that the first subscription management server or the security server of the domain in which it is located may be The terminal or smart card generation right P艮 encryption key REK or contract management key SMK. The terminal obtains the corresponding permission decryption key or the subscription management key for decryption to decrypt the received LTKM.

Meanwhile, in order to reduce the possibility that the second subscription management server repeatedly transmits the same key to the first subscription management server, and the possibility that the key is intercepted during the network transmission, the first subscription management server may save the second subscription management server. Long-term key and/or long-term key association information for a business or subscription. In this case, the first subscription management server does not necessarily request the long-term key of the service or subscription from the second subscription management server each time. After receiving the user request key message or the user confirms that the key message is to be obtained, it may first determine whether the corresponding key and the validity period of the key have been stored locally.

If the corresponding information of the key and the key, such as validity period information, is stored in the first subscription management server, the first subscription management server may determine whether the stored corresponding key is valid according to the validity period. The information of the terminal is stored in the first subscription management server, and the user in the terminal is authenticated according to the stored terminal information and the first broadcast service subscription request message sent by the terminal, so as to determine whether the user is a legitimate user. Whether the right to subscribe to the service managed by the requested second subscription management server, therefore, if the corresponding key stored in the first subscription management server is valid, steps 302 to 307 may be omitted, that is, the first subscription management server does not need Sending a second broadcast service subscription request message to the second subscription management server, and directly performing step 308, that is, the first subscription management server generates the LTKM message by using the stored corresponding key, and sends the generated LTKM message to the terminal; Or, when the corresponding key stored in the first subscription management server is valid, Steps 304-307 may be omitted. After the user service authentication by the second subscription management server, step 308 is performed, that is, the first subscription management server generates the LTKM message by using the stored long-term key, and sends the generated LTKM message. To the terminal; or, when the corresponding key stored in the first subscription management server is valid, only steps 306-307 are omitted, and step 308 is directly executed.

If the corresponding key stored in the first subscription management server has expired or expired, the first subscription management server may add an identifier to the request message sent in step 302 or 306, the identifier indicating that the first subscription management server is The long-term key has been stored, but the key has expired. After receiving the request message, the second subscription management server sends the new LTK and/or LTK related information to the first subscription management server; the first subscription management server encrypts the new LTK and sends the information to the terminal LTKM, and at the same time, A subscription management server can store new LTK and LTK related information.

If the first subscription management server stores only the corresponding key, but does not store related information of the key, such as validity period information, etc., the first subscription management server may add one of the messages sent in step 302 or 306. An identifier indicating that the long-term key has been stored in the first subscription management server. The second subscription management server may determine, according to the foregoing identifier or the history of the second subscription management server, whether the long-term key that was last sent to the first subscription management server expires; if the long-term key that was last sent to the first subscription management server does not When expired, the second subscription management server may add a message indicating that the key stored by the first subscription management server is valid in the message sent to the first subscription management server in step 307. At this time, the message in step 307 may not include a long-term key or a key group, and may also include a long-term key and/or long-term key-related information. The first subscription management server acquires the long-term key of the service from the long-term key stored in the first subscription management server according to the received message, and encrypts the long-term key; if the second subscription management The server determines that the key stored by the first subscription management server has expired, and in step 307, the second subscription The management server sends a new long-term key and/or new long-term key association information to the first subscription management server. The first subscription management server obtains the long-term key carried in the message according to the received message, and encrypts the obtained long-term key. At the same time, the first subscription management server may further replace the long-term key of the service that has been stored by using the newly acquired long-term key of the service, and replace the already stored service with the long-term key association information of the service. Long-term key association information.

The above describes the specific process of the long-term key acquisition method in the embodiment of the present invention, that is, the service ordering process. When the service key used by the user expires, if the service is still in the subscription period, the key update process is required to perform the key update. Accordingly, embodiments of the present invention also provide a method of key update (i.e., a key update procedure) for performing key update.

In the embodiment of the present invention, the key update process is basically the same as the above-mentioned service ordering process. Specifically, in the key update process, the first broadcast service subscription request message in step 301 may be replaced with a first key update request message, where the first key update request message includes a second subscription management server identifier, The user identifier, the service identifier or the subscription identifier associated with the key to be updated, and the terminal information or smart card information. The terminal information may be a terminal international mobile station device identifier (IMEI), and the smart card information may be a mobile phone SIM card number or the like. Similarly, in the key update process, the second broadcast service subscription request message in step 302 needs to be replaced with the second key update request message, and steps 303-306 can be omitted. In the key update process, step 307 will become: Send the updated long-term key to the first subscription management server; and step 308 will also become: The first subscription management server generates LTKM for the user based on the updated long-term key. And send the generated LTKM to the terminal. In the foregoing service key update process, if the first subscription management server has stored the updated key, steps 302 to 307 may be omitted, that is, the first subscription management server generates the LTKM for the user according to the updated long-term key. And sending the generated LTKM to the terminal; or, in step 302, the corresponding identifier may be included, where the identifier is specified in the first subscription management server. The updated key has been stored, and the subsequent subsequent processes are consistent with the corresponding processes in the above-described business ordering process.

In the service ordering process described above, the user is allowed to order a service or a subscription through the terminal, obtain the corresponding key, or request multiple services or subscriptions at the same time, and obtain multiple keys at the same time; Said, the same is true. Therefore, the corresponding steps in the above two processes may be transmitted by a key and/or key related information, or may be a key group composed of multiple keys and/or each key in the key group. Related information. In addition, since the generation of the long-term key message LTKM requires information about certain long-term key LTKs, if the related LTK information changes or is updated, the first subscription management server also needs to generate long-term secrets using the LTK and the updated related LTK information. Key message LTKM.

Since the LTK transmitted between the first subscription management server and the second subscription management server is critical for the secure use of the service, the transmission channel such as the transport layer between the two servers should adopt some security mechanisms. Such as IP Security Protocol (IPSec, IP Security Protocol). Since the long-term key of the second subscription management server in the above solution is exposed to the first subscription management server, there is a sufficient trust mechanism between the first subscription management server and the second subscription management server, or an operator of the two servers. A trust agreement is signed between them.

The above description is the long-term key acquisition method and the key update method in the embodiment of the present invention. In order to more clearly describe the technical solution in the embodiment of the present invention, the following will be in the DRM 2.0 manner or the initial user authentication architecture (GBA, The method of performing key protection in the manner of the present invention further describes the method for acquiring the long-term key and the method for updating the key in the embodiment of the present invention.

First Embodiment: Key protection is implemented by using DRM 2.0.

Flowchart of the method of /key update. As shown in FIG. 4, the first subscription management server includes one A service subscription/key management module is configured to receive and process a service subscription request of the terminal, and is responsible for generating a required key message for the terminal. When the DRM 2.0 method is used for key protection, the authorized issuer RI of the DRM may be located in or outside the first subscription management server. If the second subscription management server and its domain do not have an RI or the terminal cannot directly interact with the RI corresponding to the second subscription management server or the RI in the second subscription management server, the LTKM may be generated by the first subscription management server to implement the indirect Business subscription or key update. Therefore, when the terminal in the mobile broadcast system supports the DRM 2.0 mode, the subscription management server can encrypt the long-term key LTK in the DRM manner. As shown in FIG. 4, the method for implementing an indirect broadcast service subscription/key update by using the DRM 2.0 method includes the following steps:

Steps 401 to 407, which are consistent with steps 301 to 307 shown in FIG. 3, that is, the service subscription/key management module in the first subscription management server acquires a service or subscription from the service subscription/key management module of the second subscription management server. The long-term key of the item LTK ( SEAK or PEAK ).

Step 408: The service subscription/key management module of the first subscription management server sends a message requesting the trigger message (ROAPTrigger) in the rights object acquisition protocol to the authorized issuer RI, where the message needs to carry the terminal information (such as the terminal device identifier). , can carry the long-term key LTK ( SEAK or PEAK ) of the business or subscription. The RI determines whether the ROAP Trigger carries the long-term key LTK (SAEK or PEAK) of the service or the subscription. If not, the RI also needs to request the SEAK from the subscription/key management module in the first subscription management server. PEAK.

Step 409, the RI generates a permission encryption key REK for the terminal (the RI generates a REK according to the terminal information, and conforms to the DRM2.0 mechanism), encrypts the SEAK or the PEAK by using the permission encryption key, and generates a long-term key message that needs to be sent to the terminal. LTKM, the copyright object (RO) message. The RI returns a successful response (OK) message corresponding to the above ROAP Trigger to the service subscription/key management module.

Step 410: The service subscription/key management module of the first subscription management server receives the RI The ROAP Trigger successfully responds (OK) message, and sends a notification message to the terminal to trigger the acquisition of the RO, where the notification message includes an address required for acquiring the RO, and the address may be, but is not limited to, a URI; the message follows DRM 2.0. RO Tigger message definition.

Step 411: The terminal receives the message triggering the acquisition of the RO, and obtains the RO acquisition request according to the RO in the message, and the request is in accordance with the DRM 2.0 manner.

Step 412: The RI sends an RO response message to the terminal, that is, LTKM, and the message format conforms to the specification of DRM 2.0.

The above described process uses the 2 step (2 pass) RO acquisition process of DRM 2.0. If the 1 step (1 pass) RO acquisition process is used, there may be no steps 410 and 411, and the other interaction steps with RI follow. DRM 2.0's 1 pass RO acquisition process.

In the above process, the requesting ROAP Trigger message sent by the service subscription/key management module of the first subscription management server received by the RI carries the terminal device identifier, and after receiving the request ROAP Trigger message, the RI It is also necessary to perform security authentication on the terminal device to determine whether the terminal device has been registered with the RI. If the terminal device has not been registered, the RI returns a response message that the terminal has not been registered to the service subscription/key management module of the first subscription management server, and the service subscription/key management module of the first subscription management server re-registers the terminal. The response message is sent to the terminal, which triggers the terminal to register at the RI. When the terminal is registered with the RI, the terminal can obtain the required RO from the RI. If the terminal is not registered with the RI, the process of long-term key acquisition ends. The terminal's registration process in the RI and the subsequent process of acquiring the RO follow the DRM 2.0 approach.

Further, the key update procedure in this embodiment is identical to the key update procedure shown in FIG. As can be seen from this embodiment, if the terminal is not registered with the authorized issuer RI of the first subscription management server domain, the terminal can also complete the terminal registration process by registering the RI at the time of authentication, so that the terminal can obtain the long-term key.

Second Embodiment: The key protection is performed by using the GBA method. When the Smartcard smart card is used for service protection, different mechanisms are used for USIM and RUIM cards. For the USIM card defined by 3GPP, the key protection can be performed by means of GBA.

When GBA is used for mobile protection in mobile broadcasting, the subscription management server can be used as a Network Application Function (NAF) in GBA. After the bootstrapping process, the user equipment UE and the Bootstrapping Server Function (BSF) generate the key KS. The key KS may be composed of the strings CK and IK, that is, KS=CKIIIK. According to the above-mentioned key KS, the UE and the BSF can generate the subscription key KS_NAF corresponding to the NAF through the key derivation mechanism in the prior art. The subscription management server can use KS_NAF to encrypt SEAK and generate LTKM to send to the terminal.

If the subscription management server is located in a different carrier, and the second carrier does not have the GBA system or the subscription management server of the second operator cannot interact with the BSF of the first carrier, the first carrier's GBA system may be used. Implement registration and encryption of LTK to generate LTKM. In this case, the terminal first needs to obtain the KS in the BSF of the first carrier through the Bootstrapping process of the GBA, and then assist the subscription of the broadcast service of the second carrier through the GBA system of the first carrier. The specific process is as follows:

FIG. 5 is a flowchart of a method for implementing an indirect broadcast service subscription/key update by using the GBA method according to an embodiment of the present invention. As shown in Figure 5, the method of implementing the indirect broadcast service subscription/key update using the GBA method includes the following steps:

Steps 501 to 507, which are the same as steps 301 to 307 shown in FIG. 3, that is, the service subscription/key management module in the subscription management server of the first carrier is subscribed to the service from the subscription management server of the second carrier. / The key management module obtains the long-term key LTK ( SEAK or PEAK ) of the service or subscription.

Step 508, the service subscription/key management mode in the subscription management server of the first operator The block sends a message requesting KS_NAF to the BSF, and the message also needs to include user smart card information (such as SIM card number).

Step 509: The BSF returns the KS_NAF to the service subscription/key management module of the subscription management server of the first operator.

Step 510: The service subscription/key management module of the subscription service server of the first operator receives the KS_NAF, encrypts the SEAK or PEAK by using the KS_NAF, generates a long-term key message LTKM to be sent to the terminal, and sends the LTKM to the terminal.

It can be seen from the above process that when the domain of the second operator's subscription management server does not have a BSF, or the service subscription/key management module of the second subscription management server does not support the function of the GBA, This method is used to implement the acquisition of the broadcast service key based on the GBA method.

Further, the key update procedure in this embodiment is identical to the key update procedure shown in FIG. Third Embodiment: A method of obtaining a roaming service key initiated from a home.

The traditional broadcast television network is mostly a one-way television network, and some programs must be given the key to watch. When the user roams to the one-way network, it is inconvenient to sign and manage the BCAST directly through the terminal and the roaming place. The BSM (ie, the second subscription management server) interacts, or in some cases, the user wants to obtain the required broadcast roaming service key in advance before roaming.

When the terminal cannot directly interact with the roaming BSM (ie, the second subscription management server), the roaming service request can be completed through the BSM of the home SP (ie, the first subscription management server). In this case, the first subscription management server is equivalent to the BSM of the home SP, and the second subscription management server is equivalent to the roaming SP or the BSM of the roaming place. If the DRM 2.0 method is adopted, the terminal does not need to perform secure registration on the RI of the roaming SP to obtain the long-term key message LTKM.

FIG. 6 is a method for acquiring a home-originated roaming service key according to an embodiment of the present invention; Flow chart. As shown in FIG. 6, the method for home-originated roaming key acquisition includes the following steps:

Step 601: The user obtains a roaming service guide from a BCAST service distribution/adaptation (BSD/A, BCAST Service Distribution/Adaptation) of the roaming place.

Step 602: The user finds the service that is of interest to the user, and sends a request for accessing one or more roaming services to the BSM (ie, the first subscription management server) of the home SP through the terminal, where the request includes the user identifier, the service to be subscribed, or Purchase item ID and BSM ID of the roaming SP. If there are multiple SPs sharing one BSM in the roaming area, the message also needs to carry the identifier of the subscribed roaming service SP.

Step 603: After authenticating the user, the BSM of the home SP sends a roaming service authentication request to the BSM of the roaming SP, where the request includes the user identifier, the service to be subscribed, or the purchase item identifier. The message may also include terminal information or smart card information.

Step 604: The BSM of the roaming SP confirms whether the user can subscribe to the roaming service, and returns a roaming service authentication response message to the BSM of the home SP, where the authentication response result is included.

Step 605: The BSM of the home SP returns the roaming service authentication response message to the terminal. Step 606: If the user is allowed to subscribe to the requested service or the purchased item, the terminal may prompt the user to confirm the long-term key of the required service or the purchased item. After the user confirms the reception, the terminal returns a message confirming receipt of the roaming service or the purchase item key to the BSM of the home SP, and the message may further include terminal information or smart card information. That is, in steps 603 and 606, at least one message contains terminal information or smart card information.

Step 607: The BSM of the home SP requests the long-term key message LTKM from the BSM of the roaming SP, where the message includes the service or purchase item identifier that the user confirms to receive.

Step 608: The BSM of the roaming SP owns the service information, generates a long-term key LTK (SEK or PEK) of the service or the subscription, and returns the BSM to the home SP.

In step 609, the BSM of the home SP encrypts the LTK, and the generated terminal needs the LTKM. Therein, step 609 can be divided into two steps: step 609a and step 609b. In step 609a, the BSM sends the LTKM to the terminal through the interactive channel. In step 609b, the BSM sends the generated LTKM to the BSD/A, and the BSD/A sends the LTKM to the terminal by using the broadcast channel.

Step 610: The terminal receives the corresponding service, and may use the received SEK or PEK to decrypt the short-term key message, obtain the short-term key, and obtain the short-term key to obtain the encrypted service.

In the process described above, if the terminal completes the secure registration authentication of the terminal or the smart card in advance, the terminal may simultaneously request the key of one or more services or subscriptions; if an error occurs in the process described above Then, an error information message can be sent to the terminal through the home BSM.

Therefore, if the roaming ground is a one-way network, the terminal can implement the service managed by the BSM of the home network through the bidirectional network of the home and the BSM of the home, and obtain the service key managed by the BSM of the roaming place, and does not need to be in the roaming place. RI or BSF for secure registration.

Fourth Embodiment: The subscription of the service in the BSM of the SP is implemented by the BSM of the operator. Multiple SP service providers can provide broadcast services to users through the same network operator. The user's personal information, such as user identification (ie, user number), terminal information (such as the terminal's IMEI identification), and user card information, are private information for the user, and sometimes the user does not wish to expose his or her private information to the SP. In this case, when the user subscribes to the broadcast service of the SP, it may be considered to subscribe to the broadcast service managed by the service subscriber of the SP directly through the service subscription management server of the operator. FIG. 7 is a flowchart of a method for acquiring a broadcast service key initiated by an operator to a service provider according to an embodiment of the present invention. As shown in FIG. 7, the method for obtaining a broadcast service key initiated by an operator to a service provider includes the following steps: terminal or smart card authentication, which may include an operator's authentication of the user and a secure registration of the terminal to the DRM RI or Use the Smartcard method to perform the Bootstraping process of GBA. Step 701: The terminal acquires a broadcast service guide.

In step 702, the user finds the SP service that he or she is interested in, and selects the business or purchase item that he wants to order. That is, the terminal sends a message requesting a certain broadcast service of the SP to the BSM of the operator, where the service or the purchase item identifier to be subscribed, the SP identifier and the user identifier to which the service belongs, and the SP may also be included. The BSM identifier may also include terminal information or smart card information.

Step 703: The operator BSM (ie, the first subscription management server) may convert the foregoing user identifier into an alternate user identifier that is provided to the SP, and the operator's BSM sends a service authentication request to the BSM of the SP, where the substitute user identifier is included. The business or purchase item identifier of the subscription.

Step 704: The BSM of the SP authenticates the user by using the foregoing alternative user identifier, confirms whether the user can subscribe to the service, and returns a service authentication response, where the authentication result and the substitute user identifier are included.

Step 705: The operator BSM sends a broadcast service authentication response message to the user corresponding to the user identifier according to the substitute user identifier, where the authentication result is included.

Step 706: If the user is allowed to subscribe to and receive the requested service, the terminal may prompt the user whether to continue to obtain the key of the service. After the user confirms that the service key is received, the terminal returns a message confirming the acquisition of the key to the operator's BSM. The message for confirming the acquisition key includes the service or purchase item identifier to obtain the key, and may also include the user identification, terminal information or smart card information. That is, in step 702 or 706, at least one message contains terminal information or smart card information.

Step 707: The operator's BSM requests the BSM of the SP for the long-term key LTK (SEK or PEK) of the service, where the requested service or the identifier of the purchased item is included.

In step 708, the BSM of the SP returns the LTK (SEK or PEK) of the service to the BSM of the operator. Step 709: The operator BSM encrypts the LTK, generates a long-term key message LTKM required by the terminal, and sends the LTKM to the terminal.

Steps 710 ~ 711, the SP passes the BSD/A broadcast service of the operator, and the terminal can use the received SEK or PEK to decrypt the short-term key message, obtain the short-term key, and use the short-term key to decrypt the received broadcast service. Thereby obtaining the required broadcast service.

In the process described above, the terminal may request the key of one or more services or subscriptions at the same time. If an error occurs in the process described above, the BSM of the carrier may send an error information message to the terminal.

It can be seen that the method provided by the embodiment of the present invention can facilitate the mobile phone service of the operator and the SP; the SPI of the SP does not need to be set or has the function of GBA, thereby reducing the equipment cost; The first BSM of the operator is used to facilitate the monitoring of the SP by the operator. Meanwhile, since the key generated by the second subscription management server is encrypted by the first subscription management server, the second service management server is not The information of the user or the terminal needs to be obtained to implement the service ordering or key update, and the information privacy of the subscriber of the first service management server is ensured.

FIG. 8 is a structural diagram of a subscription management server in an embodiment of the present invention. As shown in FIG. 8, the subscription management server 800 in the embodiment of the present invention may include only the service subscription/key management module 801 and the key message generation module 802.

The service subscription/key management module 801 is configured to receive a first broadcast service subscription request message or a first key update request message sent by the terminal, if the service involved in the received request message is not a service subscription/density The service management/key management module 801 first performs user service authentication according to the user identifier in the received request message; after the user passes the authentication, the service subscription/key management module 801 Sending a second broadcast service subscription request or a second key update request to other subscription management servers according to the request message sent by the terminal, receiving the long-term key and/or long-term sent by the other subscription management server The key association information is transmitted to the key message generation module 802 and the long-term key and/or long-term key association information. The service subscription/key management module 801 can receive a second broadcast service subscription request or a second key update request sent by another subscription management server, if the requested service is managed by the service subscription/key management module 801. The service, the service subscription/key management module 801 performs user service authentication according to the user identifier in the received request, and returns the user service authentication result to the other subscription management server; if the user passes the authentication and needs to obtain the corresponding The long-term key, the service subscription/key management module 801 generates the service long-term key and/or long-term key association information, or obtains the stored long-term key and/or long-term key association information from the storage module 803. , return to other subscription management servers.

The key message generating module 802 is configured to generate a corresponding long-term key message according to the long-term key and/or the long-term key association information sent by the service subscription/key management module 801, and generate the generated long-term key message. Send to the terminal.

The subscription management server 800 can also include a storage module 803. The storage module 803 is configured to receive and store the long-term key and/or the long-term key association information sent by the service subscription/key management module 801, and according to the key request message of the service subscription/key management module 801. The long-term key and/or long-term key association information is sent to the service subscription/key management module 801. The service subscription/key management module 801 transmits the long-term key and/or long-term key association information obtained from the storage module 803 to the key message generation module 802.

The subscription management server 800 can also include a determination module 804. The determining module 804 may be located in the service subscription/key management module 801 or may be located outside the service subscription/key management module 801. The service subscription/key management module 801 forwards the information of the key request message and all the long-term keys stored by the storage module 803 to the determining module 804, and the determining module 804 is based on the key sent by the service subscription/key management module 801. The request message and the information of the long-term key stored in 803 are used to determine whether the long-term key required by the service subscription/key management module 801 is stored in the storage module 803, if the long-term key is stored in the storage module. In 803, the determining module 804 also needs to determine whether the long-term key is valid. The determining module 804 sends the result of the judgment to the service subscription/key management module 801, and the service subscription/key management module 801 performs the next operation according to the received judgment result, that is, when the long-term key is valid. The service subscription/key management module 801 reads the long-term key from the storage module 803; when the long-term key is invalid or the long-term key is not stored in the storage module 803, If the service corresponding to the required long-term key is the service managed by the subscription management server, the service subscription/key management module 801 generates a new long-term key and/or long-term key association information, and the newly generated long-term key is generated. And/or the long-term key association information is stored in the storage module 803; if the service corresponding to the required long-term key is not the service managed by the subscription management server, the service subscription/key management module 801 is from the corresponding other subscription management server. Obtain the long-term key of the service.

The service subscription/key management module 801 can also provide the long-term key and/or long-term key association information of the service to the RI of the DRM, and request the RI to generate the long-term key message RO required by the terminal for the terminal. If an error occurs in the above process of processing a service subscription or key update, the service subscription/key management module 801 can send an error notification to the terminal or other subscription management server. In the case of generating a long-term key by the RI, if the terminal has not yet registered with the RI, the service subscription/key management module 801 can learn from the RI that the terminal has not registered yet, and can also send a notification message to the terminal, triggering the terminal to register with the RI. .

FIG. 9 is a structural diagram of a subscription management service system according to an embodiment of the present invention. As shown in FIG. 9, the subscription management service system 900 in the embodiment of the present invention may include only: a first subscription management service server and a terminal 902;

The first subscription management server 901 is configured to receive a first request message that carries the service identifier sent by the terminal 902, and obtain a long-term key of the service corresponding to the service identifier in the first request message. The long-term key generation long-term key message, the long-term key message is sent to the terminal 902; The terminal 902 is configured to send a first request message carrying a service identifier to the first subscription management server 901, and receive a long-term key message sent by the first subscription management server 901.

The subscription management service system 900 can also include a second subscription management server 903. At this time, the first subscription management server 901 sends a second request message to the second subscription management server 903, and the second subscription management server 903 sends the corresponding long-term key to the first subscription according to the second request message. The management server 901; the first subscription management server 901 transmits the received long-term key to the terminal 902.

Subscription management service system 900 can also include: Authorized issuer 904. At this time, the first subscription management server 901 may send a request message carrying the long-term key to the authorized issuer 904; the authorized issuer 904 generates the long-term secret according to the long-term key in the received request message carrying the long-term key. The key message is sent to the terminal 901.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the present invention. Within the scope of protection.

Claims

Claim

A long-term key acquisition method, the method comprising:

Receiving, by the first subscription management server, a first request message carrying a service identifier; the first subscription management server acquiring a long-term key of the service corresponding to the service identifier in the first request message;

And generating the long-term key message according to the long-term key generation long-term key message.

The long-term key acquisition method according to claim 1, wherein the generating a long-term key message according to the long-term key, and transmitting the long-term key message comprises: a first subscription management server according to The long-term key generates a long-term key message, and sends the long-term key message;

Or the first subscription management server sends a request message carrying the long-term key to the authorized issuer; the authorized issuer generates a long-term key message according to the long-term key in the request message, and sends the long-term key message to the terminal .

The long-term key acquisition method according to claim 1, wherein the obtaining the long-term key of the service corresponding to the service identifier in the first request message comprises: acquiring the second subscription management server identifier ;

And sending, by the second subscription management server identifier, a second request message to the second subscription management server, where the second request message carries the service identifier;

Receiving a long-term key corresponding to the service identifier returned by the second subscription management server according to the second request message.

The method for obtaining a long-term key according to claim 3, wherein the obtaining the second subscription management server identifier comprises:

Obtaining a second subscription management server identifier from the first request message;

Or, the second subscription management server identifier is inferred by the service identifier in the first request message.

The long-term key acquisition method according to claim 3, wherein the first subscription management server stores a long-term key of the service or a long-term key and long-term key association information in which the service is stored, and the obtaining is performed. The long-term key of the service corresponding to the service identifier in the first request message includes:

The first subscription management server determines whether the long-term key of the service corresponding to the service identifier in the first request message is stored in the first subscription management server and the long-term key is still valid.

If yes, the first subscription management server obtains the long-term key of the service corresponding to the service identifier from the stored long-term key;

Otherwise, sending a second request message to the second subscription management server according to the second subscription management server identifier, and receiving a long-term key corresponding to the service identifier returned by the second subscription management server according to the second request message.

The long-term key acquisition method according to claim 1, wherein the first subscription management server stores a long-term key of the service, and the first request message carries the second subscription management server identifier, or the first subscription management server. Determining, by the service identifier in the first request message, the second subscription management server identifier, where the first subscription management server obtains the long-term key of the service corresponding to the service identifier in the first request message, including:

The first subscription management server sends a second request message to the second subscription management server according to the second subscription management server identifier, where the second request message carries the service identifier and the long-term service of the service corresponding to the service identifier. Identification of the key;

The first subscription management server receives a determination result of whether the second subscription management server is valid according to the second request message to the long-term key stored in the first subscription management server, and if the determination result is that the long-term key is valid, the first The subscription management server receives a message sent by the second subscription management server indicating that the long-term key stored by the first subscription management server is valid; the first subscription management server acquires the long-term key according to the message; If the result of the determination is that the long-term key is invalid, the first subscription management server receives the long-term key corresponding to the service identifier sent by the second subscription management server according to the second request message.

The long-term key acquisition method according to claim 3, 4 or 5, wherein the first request message carries a user identifier, and the second request message carries a user identifier or is converted according to the user identifier. And the receiving the second subscription management server, before receiving the long-term key corresponding to the service identifier returned by the second request message, further comprising:

The second subscription management server performs authentication according to the user identifier or the substitute user identifier in the received second request message. After the user passes the authentication, the long-term key of the service is sent to the first subscription management server. step.

The long-term key acquisition method according to claim 7, wherein after the user passes the authentication, and before the first subscription management server receives the long-term key of the service, the method further includes:

Receiving, by the first subscription management server, a response message that is returned by the second subscription management server and carrying the authentication result;

The first subscription management server sends a request long-term key message to the second subscription management server according to the received response message.

The long-term key acquisition method according to claim 8, wherein after the first subscription management server receives the response message, the first subscription management server sends a request long-term key message to the second subscription management server. Previously, the method also included:

The first subscription management server sends the subscription response carrying the authentication result to the terminal. The first subscription management server receives the acknowledgement receiving subscription service message returned by the terminal.

The long-term key acquisition method according to claim 3, 4 or 5, characterized in that The method further includes: the first subscription management server storing or updating the long-term key and the long-term key association information of the service transmitted by the second subscription management server.

The long-term key acquisition method according to claim 3, 4 or 5, wherein the receiving the second subscription management server returns a long-term key corresponding to the service identifier according to the second request message, including :

The second subscription management server determines, according to the service identifier in the received second request message, whether there is a long-term key of the service corresponding to the service identifier in the second subscription management server, and whether the long-term key needs to be updated;

If there is no long-term key of the service or the long-term key needs to be updated, the second subscription management server generates a long-term key of the service and sends the generated long-term key and/or long-term key association information to the first a subscription management server;

Otherwise, the second subscription management server sends the existing long-term key and/or long-term key association information of the service to the first subscription management server.

The long-term key acquisition method according to claim 1, wherein the generating the long-term key message according to the long-term key comprises: the first subscription management server according to the network side needs a long-term key for the service Generating a long-term key message by using a rights encryption key or a contract management key generated during encryption and the long-term key;

Or, before the generating the long-term key message according to the long-term key, the first subscription management server completes the security registration for the user; and the generating the long-term key message according to the long-term key includes: the first subscription management server A long-term key message is generated according to the rights encryption key or the contract management key generated by the user at the time of secure registration and the long-term key.

The method for acquiring a long-term key according to claim 2, wherein the request message carrying the long-term key carries a terminal device identifier; and the first subscription management server sends the long-term key to the authorized issuer. After the request message also includes:

Authorized issuer according to the terminal device identifier in the request message carrying the long-term key Determining whether the terminal has been securely registered by the authorized issuer. If the terminal has been securely registered, the authorized issuer generates a long-term key message according to the long-term key in the request message, and sends the long-term key message to the terminal; Otherwise, the authorized issuer returns a response message to the first subscription management server, requesting the terminal to perform secure registration, and after the terminal is registered, authorizing the issuer to generate a long-term key message according to the long-term key in the request message, and The long-term key message is sent to the terminal.

The long-term key acquisition method according to claim 2 or 13, wherein the authorized issuer generates a long-term key message according to the long-term key in the request message, and the long-term key message is Sending to the terminal includes:

Authorizing the issuer to encrypt the long-term key in the request message carrying the long-term key and generate a long-term key message, and send a success response message to the first subscription management server; the first subscription management server sends the acquisition long-term key to the terminal a notification message of the message; the terminal sends a request message for obtaining the long-term key message to the authorized issuer according to the notification message;

The authorized issuer sends the long-term key message to the terminal.

The long-term key acquisition method according to claim 1, wherein the generating the long-term key message according to the long-term key, and the sending the long-term key message specifically includes:

The first subscription management server sends a request for the subscription key to the boot service function module, and the first subscription management server receives the encryption key returned by the boot service function module according to the message requesting the encryption key;

The first subscription management server generates a long-term key message based on the encryption key and the long-term key, and transmits the long-term key message to the terminal.

16. A subscription management server, wherein the subscription management server comprises: a service subscription/key management module and a key message generation module;

The service subscription/key management module is configured to receive a first request message, obtain a long-term key and/or long-term key association information of a service corresponding to the service identifier in the first request message; The key and/or long-term key association information is sent to the key message generation module;

The subscription management server according to claim 16, wherein the subscription management server further comprises: a storage module;

The storage module is configured to store a long-term key and/or long-term key association information acquired or generated by a service subscription/key management module;

The service subscription/key management module reads the required long-term key and/or long-term key association information from the storage module according to the received first request message.

The subscription management server according to claim 17, wherein the subscription management server further comprises: a determination module;

The determining module is configured to determine whether a long-term key required in the subscription request message or the key update request message received by the service subscription/key management module is stored in the storage module and the long-term key is valid, and The judgment result is sent to the service subscription/key management module; the service subscription/key management module reads the required long-term key from the storage module according to the judgment result sent by the judgment module, or from the second Subscribe to the management server to get the long-term key you need.

A subscription management service system, wherein the subscription management service system comprises: a first subscription management server and a terminal;

The first subscription management server is configured to receive a first request message that is sent by the terminal and that carries a service identifier, and obtain a service that is corresponding to the service identifier in the first request message. a long-term key; generating a long-term key message according to the long-term key, and sending the long-term key message to the terminal;

The subscription management service system according to claim 19, wherein the subscription management service system further comprises: a second subscription management server;

The second subscription management server is configured to send the corresponding long-term key to the first subscription management server according to the second request message of the first subscription management server;

The first subscription management server is further configured to send a second request message to the second subscription management server, and receive a long-term key corresponding to the service identifier returned by the second subscription management server according to the second request message.

The subscription management service system according to claim 19 or 20, wherein the subscription management service system further comprises: an authorized issuer;

The first subscription management server is further configured to send a request message carrying a long-term key to the authorized issuer;

The authorized issuer is configured to receive the request message carrying the long-term key sent by the first subscription management server, generate a long-term key message according to the long-term key in the request message, and send the long-term key message Send to the terminal.