Method and apparatus for key management in mission-critical data communications

Abstract

A method and apparatus for offline key management in one-to-one mission-critical data communication is provided. The method includes: initiating an offline McData service for communicating with other client devices, obtaining a McData message including a McData protection key and an identifier of the McData protection key when a valid McData protection key for the other client devices is not available, and sending the McData message to the other client devices.

Description

Technical Field

[0001] The present disclosure relates to mission critical systems, and more particularly, to a method and apparatus for offline key management in one-to-one mission critical data (MCD) communications. Background Art

[0002] In order to meet the demand for wireless data services that has increased since the deployment of the fourth generation (4G) communication system, efforts have been made to develop improved fifth generation (5G) or pre-5G communication systems. 5G or pre-5G communication systems are also referred to as "super 4G networks" or "post-long term evolution (LTE) systems". 5G communication systems are considered to be implemented in higher frequency (mmWave) bands (such as the 60GHz band) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed with respect to 5G communication systems. In addition, in 5G communication systems, system network improvements are being developed based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, coordinated multi-point (CoMP), receiving-end interference elimination, etc. In the 5G system, hybrid frequency shift keying (FSK) and Feher's quadrature amplitude modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coding modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0003] The Internet, which is a human-centered connectivity network where humans generate and use information, is now evolving into the Internet of Things (IoT), where distributed entities such as things exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, which combines IoT technology and big data processing technology by connecting to a cloud server. For the realization of IoT, technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology" have been required, and sensor networks, machine-to-machine (M2M) communication, machine type communication, etc. have been studied recently. Such an IoT environment can provide smart Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination between existing information technology and various industrial applications, IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart appliances, and advanced medical services.

[0004] In view of this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, MTC, and M2M communications can be implemented through beamforming, MIMO, and array antennas. The application of cloud RAN, which is the above-mentioned big data processing technology, can also be considered as an example of the fusion between 5G technology and IoT technology.

[0005] As described above, various services may be provided according to the development of wireless communication systems, and thus a method for easily providing such services is required. Summary of the invention

[0006] [Technical issues]

[0007] For offline communication, key information sharing (i.e., security context establishment) needs to be completed before the electronic device (e.g., originating user, end user, user equipment (UE)) moves offline. This limits the service scenario where the UE cannot use the offline one-to-one MCD communication service and directly initiates the service when offline or moves to offline without sharing key information.

[0008] [Technical solution]

[0009] Embodiments provided are methods and apparatus for offline key management in one-to-one mission critical data (MCD) communications.

[0010] Another object of this embodiment is to initiate a request to transmit a short data service (SDS) message to a terminating MCD client device and determine whether the originating MCD client has a valid private call key (PCK) for the terminating MCD client device.

[0011] Another object of this embodiment is to generate a PCK and a private call key identifier (PCK-ID) for a terminal MCD client device when the originating MCD client does not have a valid PCK for the terminal MCD client device, and send an SDS message to the terminal MCD client device, wherein the SDS message includes an MCD service-specific element, an MCD encrypted payload, and the PCK and PCK-ID.

[0012] Another object of this embodiment is to send an SDS message to a terminating MCD client device when the originating MCD client has a valid PCK for the terminating MCD client device, wherein the SDS message includes security information. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The method is illustrated in the accompanying drawings, in which similar reference numerals represent corresponding parts in the various figures throughout the accompanying drawings. The embodiments herein will be better understood from the following description with reference to the accompanying drawings, in which:

[0014] Figure 1 A method for offline key management in a one-to-one mission critical data (MCD) communication system according to an embodiment disclosed herein is shown;

[0015] Figure 2 A block diagram of an originating MCD client device for offline key management in one-to-one MCD communication according to embodiments disclosed herein is shown;

[0016] Figure 3 A block diagram of a terminal MCD client device for offline key management in one-to-one MCD communication according to an embodiment disclosed herein is shown;

[0017] Figure 4 is a flow chart illustrating a method for offline key management in one-to-one MCD communication according to an embodiment disclosed herein;

[0018] Figure 5 is a flow chart illustrating a method for generating a private call key (PCK) and a private call key identifier (PCK-ID) for a terminal MCD client device according to an embodiment disclosed herein;

[0019] Figure 6 is a flow chart illustrating a method for sending a short data service (SDS) message to a terminal MCD client device according to an embodiment disclosed herein;

[0020] Figure 7 is a timing diagram illustrating a method for offline key management in one-to-one MCD communication according to an embodiment disclosed herein; and

[0021] Figure 8 is a flow chart illustrating a method for offline key management in one-to-one mission critical data (McData) communication by a client device according to embodiments disclosed herein. DETAILED DESCRIPTION

[0022] The present application provides a method and apparatus for offline key management in one-to-one mission-critical data communications.

[0023] Therefore, embodiments of the present invention disclose a method and apparatus for offline key management in one-to-one mission critical data (MCD) communication. The method includes initiating a request by an originating MCD client device to transmit a short data service (SDS) message to a terminal MCD client device. In addition, the method includes determining by the originating MCD client device whether the originating MCD client has a key available for the terminal MCD client device (200) for the terminal MCD client device. In addition, the method includes executing: when the originating MCD client device does not have a valid key for the terminal MCD client device, the originating MCD client device generates a key and a key identifier (KEY-ID) for the terminal MCD client device, and when the originating MCD client device has a valid key for the terminal MCD client device, the SDS message is sent to the terminal MCD client device.

[0024] In an embodiment, generating a key and KEY-ID for the terminating MCD client device includes: retrieving, by the originating MCD client device, the key material for the terminating MCD client device from a configuration of the key material. In addition, the method includes generating, by the originating MCD client device, a key and KEY-ID for the terminating MCD client device based on the key material.

[0025] In an embodiment, sending an SDS message to a terminal MCD client device includes: encrypting a key and a KEY-ID by the originating MCD client device using a unique identifier (UID) of the terminal MCD client device. In addition, the method includes generating a MIKEY-SAKKE I_MESSAGE that encapsulates the key and the KEY-ID by the originating MCD client device. In addition, the method includes signing the MIKEY-SAKKE I_MESSAGE by the originating MCD client device using the UID of the originating MCD client device to share the key and the KEY ID. In addition, the method includes sending an SDS message by the originating MCD client device to the terminal MCD client device, wherein the SDS message includes an MCD service specific element and an MCD encrypted payload including the MIKEY-SAKKE I_MESSAGE.

[0026] In an embodiment, the key used is a Private Call Key (PCK) and the key identifier used is a Private Call Key Identifier (PCK-ID).

[0027] In an embodiment, configuration of the key material is configured in the originating MCD client device and the terminating MCD client device during configuration for offline services.

[0028] In an embodiment, during configuration for offline services, a time period during which the configuration of the key material is valid is also configured in the originating MCD client device and the terminating MCD client device.

[0029] In an embodiment, when the originating MCD client device and the terminating MCD client device are in a networked service, the configuration of the key material is configured in the originating MCD client device and the terminating MCD client device by a key management server.

[0030] In an embodiment, the MCD service specific elements include the message type, the date and time when the MCD encrypted payload was created, the payload identification, the payload sequence number, and the PCK identifier.

[0031] In an embodiment, the security information only includes the PCK-ID and the MCD service specific elements and the MCD encrypted payload.

[0032] In an embodiment, in the case where the security information only includes the PCK-ID, the PCK-ID may be encapsulated in a MIKEY-SAKKE I_MESSAGE for distribution.

[0033] In an embodiment, the method further comprises receiving, by the terminal MCD client device, an SDS message from an originating MCD client device. Furthermore, the method comprises verifying, by the terminal MCD client device, the MIKEY-SAKKE I_MESSAGE of the received SDS message. Furthermore, the method comprises extracting, by the terminal MCD client device, a key and a KEY-ID from the MIKEY-SAKKE I_MESSAGE of the received SDS message. Furthermore, the method comprises decrypting, by the terminal MCD client device, the MCD-encrypted payload of the received SDS message.

[0034] Therefore, an embodiment of the present invention provides an originating MCD client device for providing an offline key management method in a one-to-one mission critical data (MCD) communication. The originating MCD client device includes a processor and a memory. The processor is configured to initiate a request to transmit a short data service (SDS) message to a terminal MCD client device. In addition, the processor is configured to determine whether the originating MCD client has a valid key for the terminal MCD client device. In addition, the processor is configured to generate a key and a key identifier (KEY-ID) for the terminal MCD client device when the originating MCD client device does not have a valid key for the terminal MCD client device, and to send an SDS message to the terminal MCD client device when the originating MCD client device has a valid key for the terminal MCD client device.

[0035] Therefore, an embodiment of the present invention provides a terminal MCD client device for providing an offline key management method in a one-to-one mission critical data (MCD) communication. The terminal MCD client device includes a processor and a memory. The processor is configured to receive an SDS message from an originating MCD client device. In addition, the processor is configured to verify the MIKEY-SAKKE I_MESSAGE of the received SDS message. In addition, the processor is configured to extract a key and a KEY-ID from the MIKEY-SAKKE I_MESSAGE of the received SDS message. In addition, the processor is configured to decrypt the MCD encrypted payload of the received SDS message.

[0036] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description, although indicating preferred embodiments and many of their specific details, is provided as an illustration rather than for limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from their spirit, and the embodiments herein include all such modifications.

[0037] [Invention Mode]

[0038] The embodiments herein and their various features and advantageous details are explained more fully with reference to the non-limiting embodiments shown in the accompanying drawings and described in detail in the following description. The description of known components and processing techniques is omitted so as not to unnecessarily confuse the embodiments herein. In addition, since some embodiments can be combined with one or more other embodiments to form new embodiments, the various embodiments described herein are not necessarily mutually exclusive. Unless otherwise indicated, the term "or" used herein refers to a non-exclusive or. The examples used herein are intended only to help understand the manner in which the embodiments herein can be implemented, and further enable those skilled in the art to implement the embodiments herein. Therefore, the examples should not be interpreted as limiting the scope of the embodiments herein.

[0039] As is conventional in the art, embodiments may be described and illustrated in terms of blocks that perform one or more functions described. These blocks (which may be referred to herein as units or modules, etc.) are physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, fixed circuits, etc., and may optionally be driven by firmware and software. The circuits may be implemented, for example, in one or more semiconductor chips, or on substrate supports such as printed circuit boards. The circuits that make up the blocks may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuits), or by a combination of dedicated hardware that performs some functions of the blocks and a processor that performs other functions of the blocks. Without departing from the scope of the present invention, each block of the embodiment may be physically divided into two or more interacting blocks and separate blocks. Similarly, without departing from the scope of the present invention, the blocks of the embodiment may be physically combined into more complex blocks.

[0040] The term "unit" used herein means a software element or a hardware element such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and performs a specific function. However, the term "unit" is not limited to software or hardware. A "unit" can be formed to be located in an addressable storage medium, or can be formed to operate one or more processors. Therefore, for example, the term "unit" can include an element (e.g., a software element, an object-oriented software element, a class element, and a task element), a process, a function, an attribute, a process, a subroutine, a program code segment, a driver, a firmware, a microcode, a circuit, data, a database, a data structure, a table, an array, or a variable.

[0041] The functions provided by the elements and "units" may be combined into a smaller number of elements and "units", or may be divided into additional elements and "units". In addition, the elements and "units" may be implemented to reproduce one or more central processing units (CPUs) in a device or a secure multimedia card. In addition, in embodiments of the present disclosure, a "unit" may include at least one processor. In the following description of the present disclosure, well-known functions or configurations are not described in detail because they would obfuscate the present disclosure with unnecessary details.

[0042] Hereinafter, for convenience of explanation, the present disclosure uses terms and names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP LTE) standard. However, the present disclosure is not limited to the terms and names, and the present disclosure may also be applied to systems complying with other standards.

[0043] The accompanying drawings help to easily understand various technical features, and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. Therefore, except for those changes, equivalent embodiments and alternative embodiments specifically listed in the accompanying drawings, the present disclosure should be interpreted as extending to any changes, equivalent embodiments and alternative embodiments. Although the terms first, second, etc. can be used to describe various elements in this article, these elements should not be limited by these terms. These terms are usually only used to distinguish one element from another element.

[0044] The Mission Critical Data (MCD) communication system allows mission critical users to communicate using data such as text, files, etc. Encryption (also integrity protection / digital signature) is used to protect communications between mission critical users, and key generation materials and credentials between mission critical users are securely provided by the key management server for encryption. The media plane security context is used to protect communications between mission critical users (i.e., end users). The media plane security context needs to be established before communication. When offline, especially for small user payloads such as the Short Data Service (SDS) of MCD communications, media plane security context establishment is a cumbersome process and should be avoided.

[0045] For one-to-one (private) MCD communication, the originating user generates a key for encryption and provides the key together with the key identification information to the end user. For offline communication, according to the current 3rd Generation Partnership Project (3GPP) standard (i.e., Release 15), key information sharing (i.e., security context establishment) needs to be completed before the electronic device (e.g., originating user, end user, user equipment (UE)) moves offline. This limits the service scenario where the UE cannot use the offline one-to-one MCD communication service and directly initiates the service offline or moves offline without sharing key information.

[0046] It would therefore be desirable to address the above-mentioned or other disadvantages, or at least provide a useful alternative.

[0047] Therefore, the embodiments of the present invention disclose a method and apparatus for performing offline key management in one-to-one mission-critical data (MCD) communication. The method includes initiating a request by an originating MCD client device to transmit a short data service (SDS) message to a terminal MCD client device. In addition, the method includes determining by the originating MCD client device whether the originating MCD client has a valid private call key (PCK) for the terminal MCD client device. In addition, the method includes: when the originating MCD client device does not have a valid PCK for the terminal MCD client device, the originating MCD client device generates a PCK and a private call key identifier (PCK-ID) for the terminal MCD client device, and when the originating MCD client device has a valid PCK for the terminal MCD client device, the SDS message is sent to the terminal MCD client device.

[0048] Referring now to the drawings and more particularly to Figures 1 to 7 , wherein like reference numerals indicate corresponding features consistently throughout the drawings, there is shown a preferred embodiment.

[0049] Figure 1 A method for performing offline key management in a one-to-one mission critical data (MCD) communication system (1000) according to an embodiment disclosed herein is shown. The MCD communication includes an originating MCD client device (100) and a terminating MCD client device (200). The originating MCD client device (100) and the terminating MCD client device (200) can be, for example but not limited to, a smartphone, a laptop, a desktop computer, a smart watch, etc.

[0050] In an embodiment, an originating MCD client device (100) is configured to initiate a request to transmit a short data service (SDC) message to a terminal MCD client device (200). In addition, the originating MCD client device (100) is configured to determine whether the originating MCD client device (100) has a valid private call key (PCK) for the terminal MCD client device (200). In addition, the originating MCD client device (100) is configured to generate a PCK and a private call key identifier (PCK-ID) for the terminal MCD client device (200) when a valid PCK is not available, and to send a short data service (SDC) message to the terminal MCD client device (200) (wherein the SDS message includes an MCD service specific element, an MCD encrypted payload, and the PCK and PCK-ID encapsulated in a MIKEY-SAKKEI_MESSAGE) or to send an SDS message to the terminal client device (200), where the SDS message includes an MCD service specific element, an MCD encrypted payload, and security information.

[0051] In an embodiment, the originating MCD client device (100) is configured to retrieve key material for the terminating MCD client device (200) from a configuration of key material. In addition, the originating MCD client device (100) is configured to generate a PCK and a PCK-ID for the terminating MCD client device (200) based on the key material.

[0052] In an embodiment, the originating MCD client device (100) is configured to encrypt the PCK and PCK-ID using the UID of the terminal MCD client device (200). In addition, the originating MCD client device (100) is configured to generate Sakai-Kasahara key encryption in the multimedia internet keyed MIKEY-SAKKE I_MESSAGE. In addition, the originating MCD client device (100) is configured to sign the MIKEY-SAKKE I_MESSAGE using the UID of the originating MCD client device (100) to share the PCK and PCK ID. In addition, the originating MCD client device (100) is configured to send an SDS message to the terminal MCD client device (200), wherein the SDS message includes an MCD service specific element, an MCD encrypted payload, and the MCD encrypted payload includes the MIKEY-SAKKE I_MESSAGE encapsulating the encrypted PCK and the encrypted PCK-ID.

[0053] In an embodiment, the terminal MCD client device (200) is configured to receive an SDS message from an originating MCD client device (100). In addition, the terminal MCD client device (200) is configured to verify the MIKEY-SAKKE I_MESSAGE of the received SDS message. In addition, the terminal MCD client device (200) is configured to extract the PCK and PCK-ID from the MIKEY-SAKKE I_MESSAGE of the received SDS message. In addition, the terminal MCD client device (200) is configured to decrypt the MCD encrypted payload of the received SDS message.

[0054] Figure 2 A block diagram of an originating MCD client device (100) for offline key management in one-to-one MCD communication according to embodiments disclosed herein is shown. The originating MCD client device (100) includes a memory (110), a processor (120) and a communicator (130).

[0055] The memory (110) also stores instructions executed by the processor (120). The memory (110) may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or an electrically programmable memory (EPROM) or an electrically erasable and programmable memory (EEPROM). In addition, in some examples, the memory (110) may be considered a non-transitory storage medium. The term "non-transitory" may mean that the storage medium is not implemented as a carrier wave or a propagating signal. However, the term "non-transitory" should not be interpreted as the memory (110) being non-removable. In some examples, the memory (110) may be configured to store a larger amount of information than the memory. In some examples, the non-transitory storage medium may store data that changes over time (e.g., in a random access memory (RAM) or a cache). The memory (110) may be an internal storage unit, or may be an external storage unit of the originating MCD client device (100), cloud storage, or any other type of external storage.

[0056] The processor (120) is configured to execute instructions stored in the memory (110) and perform various processes. The processor (120) includes a PCK engine (120a), a PCK encryption (120b), a MIKEY-SAKKE I_MESSAGE engine (120c) and an SDS message generator (120d).

[0057] In an embodiment, the PCK engine (120a) determines whether the originating MCD client device (100) has a valid PCK for the terminating MCD client device (200). In addition, when the originating MCD client device (100) does not have a valid PCK for the terminating MCD client device (200), the PCK engine (120a) generates a PCK and a PCK-ID for the terminating MCD client device (200) based on the key material. In addition, the PCK engine (120a) retrieves the key material for the terminating MCD client device (200) from a configuration of the key material.

[0058] In an embodiment, the PCK encryption (120b) encrypts the PCK and PCK-ID using the UID of the terminal MCD client device (200).

[0059] In an embodiment, the MIKEY-SAKKE I_MESSAGE engine (120c) generates the MIKEY-SAKKE I_MESSAGE. In addition, the MIKEY-SAKKE I_MESSAGE engine (120c) signs the MIKEY-SAKKE I_MESSAGE using the UID of the originating MCD client device (100) to share the PCK and PCK ID.

[0060] In an embodiment, the SDS message generator (120d) initiates a request to transmit the SDS message to the terminal MCD client device (200). In addition, the SDS message generator (120d) sends the SDS message to the terminal MCD client device (200).

[0061] The communicator (130) is configured for internal communication between internal hardware components and for communication with external devices via one or more networks.

[0062] Although Figure 2 Various hardware components of the originating MCD client device (100) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the originating MCD client device (100) may include fewer or greater numbers of components. In addition, the labels or names of the components are for illustrative purposes only and do not limit the scope of the invention. One or more components may be combined together to perform the same or substantially similar functions for offline key management in one-to-one MCD communications.

[0063] Figure 3 A block diagram of a terminal MCD client device (200) for offline key management in one-to-one MCD communication according to an embodiment disclosed herein is shown. The terminal MCD client device (200) includes a memory (210), a processor (220) and a communicator (230).

[0064] The memory (210) also stores instructions executed by the processor (220). The memory (210) may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or an electrically programmable memory (EPROM) or an electrically erasable and programmable memory (EEPROM). In addition, in some examples, the memory (210) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not implemented as a carrier or propagation signal. However, the term "non-transitory" should not be interpreted as the memory (210) being non-removable. In some examples, the memory (210) may be configured to store a larger amount of information than the memory. In some examples, the non-transitory storage medium may store data that changes over time (e.g., in a random access memory (RAM) or a cache). The memory (210) may be an internal storage unit, or may also be an external storage unit of the terminal MCD client device (200), cloud storage, or any other type of external storage.

[0065] The processor (220) is configured to execute instructions stored in the memory (210) and perform various processes. The processor (220) includes a MIKEY-SAKKE I_MESSAGE engine (220a), a PCK decryption (220b), and an SDS message extractor (220c).

[0066] In an embodiment, the MIKEY-SAKKE I_MESSAGE engine (220a) verifies the MIKEY-SAKKE I_MESSAGE message of the received SDS message. The PCK decryption (220b) extracts the PCK and PCK-ID from the MIKEY-SAKKE I_MESSAGE of the received SDS message. In addition, the PCK decryption (220b) decrypts the MCD encrypted payload of the received SDS message. The SDS message extractor (220c) receives the SDS message from the originating MCD client device (100).

[0067] The communicator (230) is configured for internal communication between internal hardware components and for communication with external devices via one or more networks.

[0068] Although Figure 3 Various hardware components of the terminal MCD client device (200) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the terminal MCD client device (200) may include fewer or greater numbers of components. In addition, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present invention. One or more components may be combined together to perform the same or substantially similar functions for offline key management in one-to-one MCD communications.

[0069] Figure 4 4 is a flowchart (400) showing a method for offline key management in one-to-one MCD communication according to an embodiment disclosed herein. Operations (402-406ab) and (402-406ba) are performed by an originating MCD client device (100). Operations (408-414) are performed by a terminating MCD client device (200).

[0070] At 402, the method includes initiating a request to transmit an SDS message to a terminal MCD client device (200). At 404, the method includes determining a valid PCK. At 406aa, the method includes generating a PCK and a PCK-ID for the terminal MCD client device (200). At 406ab, the method includes sending an SDS message with the PCK and PCK-ID generated in step 406aa and encapsulated in a MIKEY-SAKKE I_MESSAGE to the terminal MCD client device (200). At 406ba, the method includes sending an SDS message with security information to the terminal MCD client device (200).

[0071] At 408, the method includes receiving an SDS message from an originating MCD client device (100). At 410, the method includes verifying the MIKEY-SAKKE I_MESSAGE of the received SDS message. At 412, the method includes extracting the PCK and PCK-ID from the MIKEY-SAKKE I_MESSAGE of the received SDS message. At 414, the method includes decrypting the MCD encrypted payload of the received SDS message.

[0072] Figure 5 is a flow chart (406aa) illustrating a method of generating a PCK and PCK-ID for a terminal MCD client device (200) according to embodiments disclosed herein.

[0073] At 502, the method includes retrieving key material for an end MCD client device (200) from a configuration of key material. At 504, the method includes generating a PCK and a PCK-ID for the end MCD client device (200) based on the key material.

[0074] Figure 6 is a flow chart (406ab and 406ba) illustrating a method for sending an SDS message to a terminal MCD client device (200) according to an embodiment disclosed herein.

[0075] At 602, the method includes encrypting the PCK and PCK-ID using the UID of the terminating MCD client device (200). At 604, the method includes generating a MIKEY-SAKKE I_MESSAGE. At 606, the method includes signing the MIKEY-SAKKE I_MESSAGE using the UID of the originating MCD client device (100) to share the PCK and PCK ID.

[0076] Figure 7 is a timing diagram (700) illustrating a method for offline key management in one-to-one MCD communication according to embodiments disclosed herein.

[0077] In order to avoid establishing a media session for communication on the signaling plane when offline, the proposed method suggests generating a communication protection key (eg, PCK) and sharing it with the user payload on the signaling plane.

[0078] In step 702, during configuration for offline, key materials (including: user signature keys for each UID, user decryption keys for each UID, key period numbers associated with current keys) are configured in the devices (i.e., the originating MCD client device (100) and the terminating MCD client device (200)). Optionally, the period (e.g., month) during which the user key materials are valid is also configured in the device during configuration for offline. The key materials are different for each user that allows the originating McData user to make contact while offline. The key materials can be configured in the device by the key management server when the key management server is connected to the network or by an offline method.

[0079] In step 704, the McData device initiates an offline McData service for offline communication. In step 706, the McData user on the originating MCD client device (100) initiates a request to transmit a one-to-one SDS message to the terminating McData user of the terminating MCD client device (200).

[0080] At step 708, if the originating MCD client device (100) does not have a valid private call key (PCK) for the terminating MCD client device (200), the originating MCD client device (100) retrieves key material for the terminating MCD client device (200) from the configuration and generates a PCK and a private call key identifier (PCK-ID) for the terminating MCD client device (200). The PCK and PCK-ID are encrypted using the UID of the terminating MCD client device (200).

[0081] In step 710, the originating MCD client device (100) generates a MIKEY-SAKKE I_MESSAGE encapsulating the PCK and PCK-ID, and signs the MIKEY-SAKKE I_MESSAGE using the UID of the originating MCD client device (100) to share the PCK and PCK-ID.

[0082] At step 712, the originating MCD client device (100) generates a one-to-one SDS message and sends it to the terminating MCD client device (200). The one-to-one SDS message includes McData service specific elements (such as a session identifier, etc.), a user payload encrypted using the PCK generated in step 708, and the MIKEY-SAKKE I_MESSAGE generated in step -710.

[0083] At step 714, after receiving the SDS message, the terminating MCD client device (200) verifies the MIKEY-SAKKE I_MESSAGE using the IDRi element of the MIKEY-SAKKE I_MESSAGE and the configured UID of the originating MCD client device (100). At step 716, after successfully verifying the MIKEY-SAKKE I_MESSAGE, the terminating MCD client device (200) extracts the PCK and PCK-ID from the MIKEY-SAKKE I_MESSAGE.

[0084] At step 718, using the extracted PCK and PCK-ID, the terminating MCD client device (200) decrypts the user (i.e., the originating MCD client device (100)) payload and presents it to the McData user. At step 720, although the PCK generated in step 708 is valid, further one-to-one SDS messages from the originating MCData user of the originating MCD client device (100) to the terminating MCData user of the terminating MCD client device (200) include limited security information (e.g., only the PCK-ID), as well as the McData specific elements and the encrypted user payload, and do not require a full MIKEY-SAKKE I_MESSAGE.

[0085] The optimization described in step 720 may also be used during network coverage to significantly reduce message size. Key material for each user that may communicate in a one-to-one mission critical communication may be stored as a user profile for the originating user (e.g., the originating MCD client device (100)). In a protocol implementation for offline communications, the generated MIKEY-SAKKE I_MESSAGE may be sent as a TLV-E information element along with a McData specific element and a protected user payload using the MONP protocol (used by mission critical services).

[0086] In the present invention, the key and key identifier, PCK and PCK-ID are used as illustrative examples. In alternative embodiments, different encryption keys and key identifiers may be used.

[0087] Figure 8 is a flow chart illustrating a method for offline key management in one-to-one mission critical data (McData) communication by a client device according to embodiments disclosed herein.

[0088] In operation S810, a client device initiates an offline McData service for communicating with other client devices. The client device may correspond to the aforementioned originating MCD client device.

[0089] In operation S820, in the case where a valid McData protection key for other client devices is not available, the client device obtains a McData message including a McData protection key and an identifier of the McData protection key. The McData message may correspond to the above-mentioned SDS message. According to another embodiment, in the case where a valid McData protection key for other client devices is available, the client device may send a McData message without a McData protection key.

[0090] In operation S830, the client device sends a McData message to other client devices. The other client devices may correspond to the terminal MCD client device described above.

[0091] The embodiments disclosed herein may be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.

[0092] The foregoing description of specific embodiments will so fully reveal the general nature of the embodiments herein that others can easily modify these specific embodiments and / or adapt the specific embodiments to various applications by applying current knowledge without departing from the general concepts, and therefore, such adaptations and modifications should and are intended to be understood within the meaning and scope of equivalent embodiments of the disclosed embodiments. It should be understood that the words or terms used herein are for descriptive and not for limiting purposes. Therefore, although the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be implemented by modification within the spirit and scope of the embodiments described herein.

[0093] At least some of the example embodiments described herein can be constructed in part or in whole using dedicated hardware for specific purposes.Terms such as "component", "module" or "unit" used herein may include but are not limited to hardware devices, such as circuits, field programmable gate arrays (FPGA) or application-specific integrated circuits (ASIC) in the form of separate or integrated components that perform specific tasks or provide associated functions.In some embodiments, the described element may be configured to reside on a tangible, persistent, addressable storage medium, and may be configured to execute on one or more processors.In some embodiments, these functional elements may, for example, include components (such as software components, object-oriented software components, class components and task components), processes, functions, attributes, programs, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays and variables.Although example embodiments have been described with reference to components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements.Various combinations of optional features have been described herein, and it should be understood that the described features may be combined in any suitable combination. In particular, the features of any one exemplary embodiment may be appropriately combined with the features of any other embodiment, unless such combinations are mutually exclusive. Throughout the specification, the term "comprising" or "including" means including the specified components but does not exclude the presence of other components.

[0094] It should be noted that all papers and documents related to the present application that were filed concurrently with or before the present specification are disclosed to the present specification, and the contents of all these papers and documents are incorporated herein by reference.

[0095] All features disclosed in this specification (including any accompanying claims, abstract and drawings) and / or all steps of any method or process so disclosed may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive.

[0096] Unless expressly stated otherwise, each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose. Therefore, unless expressly stated otherwise, each feature disclosed is only an example of a general series of equivalent or similar features.

[0097] The invention is not limited to the details of the foregoing embodiments. The invention extends to any novel feature or any novel combination of features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel method or process step or any novel combination of steps of any method or process so disclosed.

Claims

1. A method for offline key management performed by a first client device in a one-to-one mission-critical data McData communication, the method comprising: Initiating, by the first client device, an offline McData service for performing the one-to-one McData communication with the second client device; determining whether the first client device has a valid private call key PCK for the second client device; Based on determining that there is no valid PCK for the second client device, the first client device obtains a McData message, the McData message including a PCK in a TLV-E format and an identifier ID of the PCK; and The McData message is sent to the second client device.

2. The method according to claim 1, wherein: The McData message includes a message type, a payload identifier, a payload sequence number, a date and time when the encrypted payload is created, an ID of the PCK, and a MIKEY-SAKKE I message in the TLV-E format.

3. The method according to claim 2, wherein: The PCK is encapsulated in a MIKEY-SAKKE I message included in the McData message.

4. The method according to claim 1, further comprising: Based on determining that there is the valid PCK for the second client device, the McData message is sent to the second client device without the PCK.

5. The method according to claim 4, wherein: The McData message includes a message type, a payload identifier, a payload sequence number, a date and time when the encrypted payload is created, and an ID of the PCK.

6. The method according to claim 1, wherein: Key material is provided in the first client device, and the McData message including the PCK is obtained based on the key material.

7. The method according to claim 6, wherein: The validity of the key material is limited in time.

8. A first client device for offline key management in one-to-one mission-critical data McData communication, the first client device comprising: Transceiver; as well as at least one processor coupled to the transceiver and configured to: initiating an offline McData service for performing the one-to-one McData communication with the second client device, determining whether the first client device has a valid private call key PCK for the second client device; Based on determining that there is no valid PCK for the second client device, obtaining a McData message, the McData message including a PCK in a TLV-E format and an identifier ID of the PCK, and The transceiver is controlled to send the McData message to the second client device.

9. The first client device according to claim 8, wherein: The McData message includes a message type, a payload identifier, a payload sequence number, a date and time when the encrypted payload is created, an ID of the PCK, and a MIKEY-SAKKE I message in the TLV-E format.

10. The first client device according to claim 9, wherein: The PCK is encapsulated in a MIKEY-SAKKE I message included in the McData message.

11. The first client device according to claim 8, wherein: The at least one processor is further configured to: Based on determining that there is the valid PCK for the second client device, the transceiver is controlled to send the McData message without the PCK to the second client device.

12. The first client device according to claim 11, wherein: The McData message includes a message type, a payload identifier, a payload sequence number, a date and time when the encrypted payload is created, and an ID of the PCK.

13. The first client device according to claim 8, wherein: Key material is provided in the first client device, and the McData message including the PCK is obtained based on the key material.

Images