Method and apparatus for transmitting security information in a content distribution network

Abstract

The present invention discloses a method and device for providing user key material from a server to a client. The method includes receiving a first message from a client in a server, the first message having a user key material request, an access token, and an identifier (TrK‑ID) of a transmission key, verifying the user key material request according to the access token, generating a response having the user key material in response to the user key material request, encrypting the response according to a transmission key (TrK), and transmitting a second message including the response from the server to the client. The client decrypts the second message according to the transmission key (TrK); and verifies the second message using the identifier (TrK‑ID) of the transmission key.

Description

[0001] Inventor: Xin Qiu

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 937,768, filed by Xin Qiu on November 19, 2019, entitled “TRANSMISSION OF SECURE INFORMATION IN A CONTENT DISTRIBUTION NETWORK,” which is incorporated herein by reference. background 1. Technical Field

[0005] The present disclosure relates to systems and methods for securely transmitting information in a content distribution network, and more particularly, to systems and methods for transmitting cryptographic keys and other sensitive information within the network. 2. Background technology

[0007] The distribution of content such as media programs and other data is performed via cable transmission, satellite transmission and transmission via the Internet. Increasingly, such distribution is performed to mobile devices using wireless broadband networks such as LTE (Long Term Evolution).

[0008] 5G is the fifth generation of cellular network technology, which can also be used to transmit data, but at a higher rate than LTE and previous broadband cellular network technologies. The "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security of the mission critical service; (Release 16)" (hereinafter referred to as the 3GPPP specification) released by the 3rd Generation Partnership Project (3GPPP) in September 2019 describes the security architecture, processes and information flows required to protect the mission critical services inherent in applications, such as mission critical services (MCX) including mission critical push-to-talk (MCPTT), mission critical video (MCVideo) and mission critical data (MCData), which is incorporated by reference and referred to as the 3GPPP document.

[0009] This specification describes the process of providing key material from a key management server to a key management client. Although such key material can be securely provided within a secure hypertext transfer protocol (HTTPS) architecture using encrypted communications, additional security is required. Summary of the invention

[0010] This summary is provided to introduce a selection of concepts in a simplified form, which are further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In order to address the above requirements, this document discloses a system and method for providing user key material from a server to a client. In one embodiment, the method includes receiving a first message from a client in a server, the first message having a user key material request, an access token, and an identifier of a transmission key (TrK-ID), verifying the user key material request according to the access token, generating a response with the user key material in response to the user key material request, encrypting the response according to the transmission key (TrK), and transmitting a second message including the response from the server to the client. In one embodiment, the client decrypts the second message according to the transmission key (TrK); and verifies the second message using the identifier of the transmission key (TrK-ID).

[0011] Other embodiments are demonstrated by a processor communicatively coupled to a memory storing processor instructions including instructions for performing the foregoing operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Referring now to the drawings, wherein like reference numerals designate corresponding parts throughout the several views:

[0013] Figure 1 is a schematic diagram showing a key management functional model;

[0014] Figure 2A and 2B A schematic diagram illustrating a security process for key management is given;

[0015] Figure 3 is a schematic diagram illustrating exemplary processing steps for providing user key material from a server to a client; and

[0016] Figure 4 is a schematic diagram of an exemplary computer system presenting processing elements that may be used to implement a geolocation system. DETAILED DESCRIPTION

[0017] In the following description, reference is made to the accompanying drawings which form a part hereof and which show by way of illustration several embodiments. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present disclosure.

[0018] Overview

[0019] For key management authorization, the key management client in the user device presents an access token to the key management server via HTTP. An access token is a short-lived token that conveys the identity of the user. It contains an MC service ID for at least one authorized service. The key management server verifies the access token and, if successful, transmits one or more sets of user-specific key material back to the user device key management client based on the MC service IDs (MCPTT ID, MCVideo ID, and / or MCData ID) present in the access token. User-specific key material includes identity-based key information for media and signaling protection. This key management authorization can be repeated for each KM service (MCPTT, MCVideo, MCData) that the user is authorized to use. In order to ensure that user-specific key material is transmitted from the KMS to the KMS client when using TrK and InK, the KM client includes the TrK-ID and InK-ID in the key management authorization request.

[0020] When using TrK to protect the transmission of key material between the KMS client and the KMS, the KMS client provides the mission-critical user device TrK identifier (TrK-ID) to the KMS during user key management authorization. If the InK-ID is not provided in the same user authorization request, the TrK is used for integrity protection. If the InK-ID is provided in the same user authorization request, the InK is used for integrity protection.

[0021] Figure 1 Schematic diagram of key reference points CSC-8, CSC-9 and CSC-10 for a key management server paradigm 100 within a mission critical (MC) domain. These reference points include one or more key management clients 110A-110C (hereinafter referred to as KMC or key management client 110), each having a corresponding trusted storage device 114A-114C communicatively coupled to a key management server (KMS) 112, typically through a common service core (CSC) 104. The key management clients 110 may include a key management client 110A incorporated into a group management server 102, a key management client 110B incorporated into an MCX server 106, and a key management client 110C incorporated into a user equipment (UE) 108. Any key management client 110 is responsible for interfacing with a key management server 112 to request identity specific key material from the key management server 112. The transmission of key material between the KMS 112 and the KMC 110 is protected by using a transport key (TrK) to encrypt the key material before it is transmitted from the KMS 112 to the KMC 110 .

[0022] The KMS 112 may or may not be located within the Common Services Core (CSC) 104 of the MC domain, and may or may not use the HTTP proxy. If the KMS does not use an HTTP proxy, a secure HTTP connection (HTTPS) is established directly between the KMS server 112 and the KMS client 110. In this case, each of CSC-8, CSC-9, and CSC-10 is a direct HTTP connection between the KMS server 112 and the KMS client 110 in the MC UE, MCX server, or group management server (GMS) (resp). The use of TrK defined in clause 9.3.3 can be used to protect the key material content in this configuration, and InK can be used to integrity protect the key material content. If the KMS 112 does connect to and use an HTTP proxy, then for public safety users, TrK should be used as defined in clause 9.3.3 of the 3GPPP document to protect the key material content, and InK should be used for integrity protection. In this case, each of CSC-8, CSC-9, and CSC-10 uses HTTP-1 and HTTP-2 between the KMS server and the KMS client in the MC UE, MCX server, or GMS.

[0023] Figure 2A 1 is a schematic diagram of a secure flow for key management and provision of user key material from a key management server 112 to a key management client 110 via a proxy such as an HTTP proxy (which may consist of any of the key management clients described above). The key management client (KMC) 110 establishes a connection with the key management server (KMS) 112, as shown in step 0. Like other elements in the common service core 104, this connection is routed through and secured by the HTTP proxy. The following message flows within this secure connection. This message may be secured by the HTTP proxy and may be sent over secure HTTP (HTTPS).

[0024] KMC 110 requests user key material from KMS 112 by transmitting an access token, as shown in step 1. As further described below, the request contains an access token for authenticating the user, as defined in Section 5.1 of the 3GPPP specification. The request should also contain a TrK-ID and may contain an InK-ID. The request may include any of the following:

[0025] KMSInit Request. This request is the first request sent to the KMS to set up a user. This type of request is allowed for home KMS or migration KMS.

[0026] KMSKeyProv Request: This request is intended to obtain new key material from the KMS. The request may contain details of a specific identity (e.g., MCPTT ID) required for key management, and may contain a specific time when the key material is needed. Such requests are allowed for a Home KMS or a Migration KMS.

[0027] KMSCertCache Request: This request is intended to obtain an external KMS certificate associated with an external security domain (managed by another KMS). The request may contain details of the latest version of the cache received by the client. This request can only be made to the home KMS.

[0028] KMS Redirect Response (KRR) upload: This process uploads the KRR received by the client to the home KMS. This message can only be sent to the home KMS.

[0029] KMS Cert Request: This request is to obtain a single KMS certificate based on the provided KMS URI.

[0030] KMS Lookup: This message is to look up the external KMS that should be used for the provided SIP URI.

[0031] KMS Redirect Upload: This message is to upload the received discovery request response to KMS for auditing.

[0032] The KMS 112 authenticates the request using the access token.The request also includes an identifier of the transport key (TrK) (eg, TrK-ID) and may contain an optional identifier of the integrity key (InK) (eg, InK-ID).

[0033] The request for user key material may include or be included with a request to provision a user, a request to obtain new key material from the KMS 112 , or a request to obtain an external KMS 112 digital certificate.

[0034] KMS 112 provides a response based on and in response to the authenticated user and the authenticated user request. The response may include new key material, optionally, a new transport key (TrK) or integrity key (InK), and a digital certificate associated with an identifier of the integrity key or the user identity.

[0035] The new key material is encrypted using a transport key (TrK) and may also be signed by a transport key or an integrity key (InK). The transport key (TrK), integrity key (InK) and their identifiers (TrK-ID, InK-ID) are initially provided to the KMC 110 via out-of-band (OOB) transmission and stored in a tamper-resistant or tamper-proof storage device, such as the trusted storage device 114 of the KMC 110.

[0036] Responses include:

[0037] • KMSInit Response. This response contains domain parameters and, optionally, a new TrK and / or a new InK.

[0038] • KMSKeyProv Response: This response provides the user with new key material and, optionally, a new TrK and / or a new InK.

[0039] KMSCertCache Response: This response contains the new or updated home KMS certificate and / or external KMS certificate required for the user to communicate with the external security domain.

[0040] KMS Cert Response: This response is a KMSCertCacheResponse containing a single KMS certificate (or an error message).

[0041] KMS Lookup Response: This response is intended to provide information to the client related to the discovery lookup request. Provides the KMS URI that should be used for the user, or provides permission to use a specific external KMS.

[0042] Figure 2BSchematic diagram of a secure process for key management and providing user key material from a key management server 112 to a key management client 110 without an agent (the key management client can be composed of any of the key management clients described above). In step 0, the key management client establishes a direct HTTPS connection with the KMS. The following message flow is within this secure connection. In step 1, the key management client makes a request to the KMS. As described below, the request may include a TrK-ID and may include an InK-ID. The same request may be made as defined for the agent above. In step 2, the KMS provides a response based on the authenticated user and the user's request. Optionally, the key material itself may also be encrypted using a 256-bit transport key (TrK). The response may also be signed using a TrK or InK. TrK and InK are initially distributed through an out-of-band mechanism along with their 32-bit identifiers (TrK-ID and InK-ID, respectively). As a result of this process, the key management client has securely obtained key material for use within the MC system.

[0043] To further ensure the security of the above-mentioned exchange protocol, the transport key identifier (TrK-ID) and / or the integrity key identifier (InK-ID) may be compromised because they are only protected by the security provided by the communication link (e.g., HTTPS) when transmitted from the KMC 110 to the KMS 112. In order to prevent or at least detect such compromise, the aforementioned protocol is modified so that the transport key identifier (TrK-ID) (and optionally the integrity key identifier (InK-ID)) is included in the key material before being encrypted by the transport key (TrK). The KMC 110 can then compare the value of the decrypted transport key identifier (TrK-ID) with the value of the transport key identifier (TrK-ID) in its trusted repository to verify the response before performing further processing.

[0044] Figure 33 is a schematic diagram showing exemplary processing steps for providing user key material from a server such as KMS 112 to a client such as KMC 110. In block 302, a first message is received at KMS 112 from KMC 110, the first message having a user key material request, an access token, and a transport key identifier (TrK-ID). In block 304, the user key material request is verified based on the access token. In block 306, a response having the user key material is generated in response to the user key material request. In block 308, the response is encrypted based on the transport key (TrK) identified in the request. In block 310, a second message including the response is transmitted from KMS 112 to KMC 110. In block 312, the second message is decrypted by the requesting KMC 110 based on the transport key (TrK), and in block 314, the second message is verified by comparing the decrypted transport key identifier (TrK-ID) with the stored transport key identifier (TrK-TD) using the identifier of the transport key (TrK-ID).

[0045] In one embodiment, the identifier of the transport key (TrK-ID) or the identifier of the integrity key (InK-ID) forms part of a digital certificate authenticated by a trusted entity, such as a certificate authority (CA), and the second message is verified via the digital certificate. The second message is verified using the digital certificate of the sender (KMC 110), which is verified by its certificate chain leading to the root. The identifier of the transport key (TrK-ID) (or the identifier of the integrity key (InK-ID)) is extracted from the sender's certificate after the certificate chain verification, and then, they can be compared with the identifier of the transport key (TrK-ID) or the identifier of the integrity key (InK-ID) received in the first message. TrK-ID and InK-ID are not necessarily limited to identifiers. Instead, they can include a user profile or any information that uniquely identifies a user.

[0046] In another embodiment, the KMS 112 generates a response that further includes an identifier of the transport key (TrK-ID). For example, the identifier of the transport key (TrK-ID) may simply be concatenated with the user key material (e.g., user key material|TrK-ID). Upon receipt of the second message, the KMC 110 decrypts the message, thereby decrypting and recovering the identifier of the transport key, and compares the decrypted value of the identifier of the transport key with the identifier of the transport key stored in the trusted storage device 114. Only when the two values ​​match is the second message authenticated.

[0047] In another embodiment, the second message also includes an identifier of the transmission key (TrK-ID), and the KMC compares the decrypted value of the identifier of the transmission key with the identifier of the transmission key (TrK-ID) received in the second message. Likewise, the second message is authenticated only if the two values ​​match.

[0048] In a further embodiment, an integrity key ID (InK-ID) may be included with the first message and included in the response prior to encryption by the KMS. Upon decryption of the second message, an identifier of the integrity key ID (InK-ID) may be extracted and compared to an identifier of the integrity key ID (InK-ID) stored in a trusted storage device or included as part of the second message. In either case, the second message is authenticated only if the two values ​​match.

[0049] Hardware Environment

[0050] Figure 4 An exemplary computer system 400 is shown that can be used to implement the processing elements of the above disclosure, including KMC 110 and KMS 112. Computer 402 includes processor 404 and memory, such as random access memory (RAM) 406. Computer 402 is operably coupled to display 422, which presents images, such as windows, to a user on a graphical user interface 418B. Computer 402 can be coupled to other devices, such as keyboard 414, mouse device 416, printer 428, etc. Of course, those skilled in the art will recognize that any combination of the above components or any number of different components, peripherals, and other devices can be used with computer 402.

[0051] Typically, the computer 402 operates under the control of an operating system 408 stored in memory 406, and interfaces with a user to accept input and commands and present results through a graphical user interface (GUI) module 418A. Although the GUI module 418B is depicted as a separate module, the instructions for performing GUI functions may reside or be distributed in the operating system 408, the computer program 410, or implemented using dedicated memory and a processor. The computer 402 also implements a compiler 412 that allows application programs 410 written in a programming language such as COBOL, C++, FORTRAN, or other languages ​​to be translated into code readable by the processor 404. Once completed, the application programs 410 access and manipulate data stored in the memory 406 of the computer 402 using the relationships and logic generated by the compiler 412. The computer 402 also optionally includes external communication means, such as a modem, a satellite link, an Ethernet card, or other means for communicating with other computers.

[0052] In one embodiment, the instructions implementing the operating system 408, the computer program 410, and the compiler 412 are tangibly embodied in a computer-readable medium, such as a data storage device 420, which may include one or more fixed or removable data storage devices, such as a zip drive, a floppy disk drive 424, a hard drive, a CD-ROM drive, a tape drive, etc. In addition, the operating system 408 and the computer program 410 consist of instructions that, when read and executed by the computer 402, cause the computer 402 to perform the operations described herein. The computer program 410 and / or the operating instructions may also be tangibly embodied in the memory 406 and / or the data communication device 430, thereby making a computer program product or article of manufacture. Therefore, as used herein, the terms "article of manufacture," "program storage device," and "computer program product" are intended to encompass a computer program accessible from any computer-readable device or medium.

[0053] Without departing from the scope of the present disclosure, those skilled in the art will recognize that many modifications may be made to this configuration. For example, those skilled in the art will recognize that any combination of the above components or any number of different components, peripherals, and other devices may be used.

[0054] The above discloses a device, method and system for providing user key material from a server to a client, including: receiving a first message from a client in the server, the first message having a user key material request, an access token and an identifier of a transmission key (TrK-ID); verifying the user key material request according to the access token; generating a response having the user key material in response to the user key material request; encrypting the response according to the transmission key (TrK); and transmitting a second message including the response from the server to the client; wherein the client: decrypts the second message according to the transmission key (TrK); and verifies the second message using the identifier of the transmission key (TrK-ID).

[0055] Implementations may include one or more of the following features:

[0056] Any of the above methods, wherein the response further includes an identifier of the transmission key (TrK-ID); the client decrypts the second message based on the transmission key (TrK) to recover the decrypted identifier of the transmission key (TrK-ID), and verifies the second message using the decrypted identifier of the transmission key (TrK-ID).

[0057] Any of the above methods, wherein the second message further includes an identifier of the transmission key (TrK-ID); and the second message is verified by comparing the identifier of the decrypted transmission key (TrK-ID) of the second message with the identifier of the transmission key (TrK-ID) of the decrypted message.

[0058] Any of the above methods, wherein the first message also includes an identifier (InK-ID) of the integrity key; the response also includes an identifier (InK-ID) of the integrity key; the second message also includes an identifier (InK-ID) of the integrity key; the client decrypts the second message based on the transport key (TrK) to further recover the decrypted identifier (InK-ID) of the integrity key, and uses the decrypted identifier (InK-ID) of the integrity key to verify the second message.

[0059] Any method above, wherein the encrypted response is signed by a transport key or an integrity key, and the verification is further performed based on the signed encrypted response.

[0060] Any method above, wherein the transport key identifier (TrK-ID) forms part of a digital certificate authenticated by the trusted entity, and the second message is authenticated via the digital certificate.

[0061] Any method above, wherein the transport key identifier (TrK-ID) is stored in a tamper-resistant storage device of the client device.

[0062] One embodiment is demonstrated by a device for providing user key material from a server to a client, the device comprising: a processor; a memory, the memory being communicatively coupled to the processor and storing processor instructions, the processor instructions comprising processor instructions for: receiving a first message from a client in a server, the first message having a user key material request, an access token, and an identifier of a transport key (TrK-ID); verifying the user key material request based on the access token; generating a response having the user key material in response to the user key material request; encrypting the response based on a transport key (TrK); and transmitting a second message including the response from the server to the client; wherein the client: decrypts the second message based on the transport key (TrK); and verifies the second message using the identifier of the transport key (TrK-ID).

[0063] in conclusion

[0064] The conclusion includes a description of the preferred embodiments of the present disclosure. The foregoing description of the preferred embodiments has been presented for the purpose of illustration and description. This is not intended to be exhaustive or to limit the present disclosure to the precise form disclosed. In view of the above teachings, many modifications and variations are possible. It is intended that the scope of rights is not limited by this detailed description, but by the claims attached hereto.

Claims

1. A method for providing user key material from a server to a client, comprising: (a) receiving, in the server, a first message from the client, the first message having a user key material request, an access token and an identifier of a transport key TrK-ID; (b) verifying the user key material request based on the access token; (c) generating a response having user key material in response to the user key material request; (d) encrypting the response according to the transmission key TrK identified by the identifier of the transmission key TrK-ID; (e) transmitting a second message including the encrypted response from the server to the client; (f) wherein the second message is configured to be decrypted based on the transmission key TrK, and the second message is configured to be verified using an identifier TrK-ID of the transmission key; and (g) Wherein, the response also includes an identifier of the transmission key TrK-ID.

2. The method according to claim 1, wherein: The second message is further configured to be decrypted according to the transmission key TrK to recover the identifier of the decrypted transmission key TrK-ID, and the second message is further configured to be verified using the identifier of the decrypted transmission key TrK-ID.

3. The method according to claim 2, wherein: The second message is further configured to be authenticated by comparing an identifier TrK-ID of a decrypted transmission key of the second message with an identifier TrK-ID of the transmission key of the first message.

4. The method according to claim 2, wherein: The first message also includes an identifier InK-ID of the integrity key; The response also includes an identifier InK-ID of the integrity key; The second message further comprises an identifier InK-ID of the integrity key; and The second message is configured to be decrypted according to the transmission key TrK to further recover the decrypted integrity key identifier InK-ID, and the second message is configured to verify the second message using the decrypted integrity key identifier InK-ID.

5. The method according to claim 4, wherein: The encrypted response is signed by the integrity key or the transport key, and further verification is performed based on the signed encrypted response.

6. The method according to claim 1, wherein: The identifier of the transport key TrK-ID is stored in a tamper-proof storage device of the client device.

7. A method for providing user key material from a server to a client, comprising: (a) receiving, in the server, a first message from the client, the first message having a user key material request, an access token and an identifier of a transport key TrK-ID; (b) verifying the user key material request based on the access token; (c) generating a response having user key material in response to the user key material request; (d) encrypting the response according to the transmission key TrK identified by the identifier of the transmission key TrK-ID; (e) transmitting a second message including the encrypted response from the server to the client; (f) wherein the second message is configured to be decrypted according to the transmission key TrK, and the second message is configured to be verified using an identifier TrK-ID of the transmission key; (g) wherein the identifier of the transport key TrK-ID forms part of a digital certificate authenticated by a trusted entity, and the second message is authenticated via the digital certificate.

8. An apparatus for providing user key material from a server to a client, comprising: processor; a memory communicatively coupled to the processor and storing processor instructions, the processor instructions including processor instructions for: (a) receiving, in the server, a first message from the client, the first message having a user key material request, an access token and an identifier of a transport key TrK-ID; (b) verifying the user key material request based on the access token; (c) generating a response having user key material in response to the user key material request; (d) encrypting the response according to the transmission key TrK identified by the identifier of the transmission key TrK-ID; (e) transmitting a second message including the encrypted response from the server to the client; (f) wherein the second message is configured to be decrypted according to the transmission key TrK, and the second message is configured to be verified using an identifier TrK-ID of the transmission key; (g) Wherein, the response also includes an identifier of the transmission key TrK-ID.

9. The apparatus of claim 8, wherein: The second message is further configured to be decrypted according to the transmission key TrK to recover the identifier of the decrypted transmission key TrK-ID, and the second message is further configured to be verified using the identifier of the decrypted transmission key TrK-ID.

10. The apparatus of claim 9, wherein: The second message is further configured to be authenticated by comparing an identifier TrK-ID of a decrypted transmission key of the second message with an identifier TrK-ID of the transmission key of the first message.

11. The apparatus of claim 9, wherein: The first message also includes an identifier InK-ID of the integrity key; The response also includes an identifier InK-ID of the integrity key; The second message further comprises an identifier InK-ID of the integrity key; and The second message is configured to be decrypted according to the transmission key TrK to further recover the decrypted integrity key identifier InK-ID, and the second message is configured to verify the second message using the decrypted integrity key identifier InK-ID.

12. The device according to claim 11, wherein The encrypted response is signed by the transport key or the integrity key, and further verification is performed based on the signed encrypted response.

13. The apparatus according to claim 8, wherein: The identifier of the transport key TrK-ID forms part of a digital certificate authenticated by a trusted entity, and the second message is authenticated via the digital certificate.

14. The apparatus according to claim 8, wherein: The identifier of the transport key TrK-ID is stored in a tamper-proof storage device of the client device.

15. A method for receiving user key material from a server by a client, comprising: (a) providing a first message from the client to the server, the first message having a user key material request, an access token and an identifier of a transport key TrK-ID; (b) wherein the first message is configured in a manner such that the user key material request is authenticated based on the access token; (c) receiving, by the client from the server, a second message comprising an encrypted response; (d) wherein the encrypted response is encrypted in response to the transport key TrK identified by the user key material request according to the identifier TrK-ID of the transport key with the user key material; (e) wherein the encrypted response further includes an identifier of the transport key TrK-ID; (f) decrypting the second message according to the transmission key TrK; and (g) verifying the second message using the identifier of the transport key TrK-ID.

16. The method according to claim 15, further comprising, wherein, The identifier of the transport key TrK-ID forms part of a digital certificate authenticated by a trusted entity, and the second message is authenticated via the digital certificate.

Images