JP2016530732A - Secure group generation in proximity-based service communication - Google Patents

Abstract

A method for forming a secure group in ProSe communication requests a service request from a requesting device (21) to a ProSe server, and the service request includes a request to communicate with a receiving device (22) from the requesting device (21). The ProSe server 24 verifies the request and receiving devices (21) and (22) and informs the request and receiving devices (21) and (22) to ProSe to notify that the group member is authorized. Sending a service result and initiating group security establishment of the group including said request and receiving devices (21) and (22). [Selection] Figure 6

Description

  The present invention relates to a secure system and a method for forming a secure group, and more particularly, to a secure system that provides a method for forming a secure group in proximity based service (ProSe) communication.

  The 3rd Generation Partnership Project (3GPP) has started research on Proximity based Services (ProSe) for the use of both commercial and public safety. 3GPP SA1 (Service Working Group) has initiated several security requirements for secure communication, UE (User Equipment) identification, and privacy protection.

  ProSe represents a huge social technology trend in recent years. The principles of these applications are to find instances of applications that run on terminals that are in close proximity to each other and to eventually exchange application related data. In parallel, there is an interest in proximity-based discovery and communication in the public safety community.

  ProSe communication can provide services to UEs in proximity via eNB (Evolved Node B) or without eNB. SA1 requires that the ProSe service is provided to UEs in / out of network coverage. The UE may discover other neighboring UEs or be discovered by other UEs. And UE can communicate with each other. Some use cases are described in Non-Patent Document 1. The ProSe server is a network element as agreed in Non-Patent Document 2 in 3GPP SA2 # 97.

3GPP TR 22.803 Feasibility study for Proximity Services (ProSe), (Release 12) 3GPP TR 23.703 Study on architecture enhancements to support Proximity Services (ProSe) (Release 12)

  However, despite not only privacy issues but also security issues related to authorization, 3GPP SA3 does not provide a security solution.

  The present invention has provided an overall security solution for the security issues described above.

  In one aspect, a method for forming a secure group in Proximity based Service (ProSe) communication by a requesting device that requests communication and a receiving device that receives a communication request from the requesting device is provided, and the request and The receiving device subscribes to ProSe, and the method requests a service request from the requesting device to a ProSe server, the service request including a request to communicate with the receiving device from the requesting device; The ProSe server verifies the request and receiving device, sends a ProSe service result to the request and receiving device to notify that the group member is authorized, and group security of the group including the request and receiving device Including starting the establishment.

  In another aspect, comprising: a requesting device that requests communication; and a receiving device that receives a communication request from the requesting device, and a plurality of user equipments (User Equipments (UEs)) and a proximity based service (Proximity based Service) (ProSe)) A secure system comprising a server is provided. The requesting device and the receiving device subscribe to a ProSe service. The requesting device requests a service request from the ProSe server, and the service request includes a request for communicating with the receiving device from the requesting device. The ProSe server verifies the request and receiving device. The ProSe server sends a ProSe service result to the request and receiving device to notify that group members are allowed. The requesting and receiving device initiates group security establishment for the group that includes the requesting and receiving device.

  A secure system and a method for forming a secure group in Proximity based Service (ProSe) can provide a solution for a security problem.

The above and other objects, advantages and features of the present invention will become more apparent from the following description of certain preferred embodiments in conjunction with the accompanying drawings.
FIG. 1A is a schematic diagram showing a ProSe communication scenario in Non-Patent Document 1. FIG. FIG. 1B is a schematic diagram showing a ProSe communication scenario in Non-Patent Document 1. FIG. 2 is a schematic diagram illustrating an example of a system that provides a method for performing secure communication according to an embodiment of the present invention. FIG. 3 is a schematic diagram showing a secure system according to an embodiment of the present invention. FIG. 4 is a sequence diagram illustrating a method for performing secure communication according to the embodiment of this invention. FIG. 5A is a schematic diagram showing a one-to-one session. FIG. 5B is a schematic diagram illustrating a one-to-many session. FIG. 5C is a schematic diagram illustrating a many-to-many session. FIG. 6 is a flowchart illustrating a method for performing group management in case 1C according to the embodiment.

  Here, for purposes of the following description, the terms “top”, “bottom”, “right”, “left”, “vertical”, “horizontal”, “top”, “bottom”, “side”, “ “Vertical” and their derivatives are relevant to the present invention as shown in the drawings. However, it is understood that the invention may take various alternative variations and process sequences except where expressly specified to the contrary. It is also understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary embodiments of the invention. Accordingly, the particular dimensions and other physical characteristics associated with the embodiments disclosed herein are not to be considered limiting.

  In the exemplary embodiment, through the description of a security solution centered on direct communication, discovery and communication in particular, the solution can be applied to other communications as well.

  First, the definitions given in 3GPP TR 21.905 “Vocabulary for 3GPP Specifications” are explained.

ProSe Direct Communication:
Communication between two or more UEs in a ProSe-enabled proximity by user plane transmission using E-UTRA technology over any network node unrouted path.

ProSe capable UE:
A UE that supports ProSe requirements and associated processing. Unless otherwise stated, ProSe capable UEs refer to both non-public safety UEs and public safety UEs.

ProSe-enabled Public Safety UE:
ProSe capable UE that also supports functions specific to ProSe processing and public safety.

ProSe-enabled non-public safety UE:
UE that supports ProSe processing but does not support features specific to public safety.

ProSe Direct Discovery:
The process employed by a ProSe-capable UE to discover other ProSe-capable UEs around it by using only the functions of the two UEs using Release 12 E-UTRA technology.

EPC-level ProSe Discovery:
Processing by the EPC determining the proximity of two ProSe capable UEs and notifying their proximity.

  1A and 1B are schematic diagrams showing a ProSe communication scenario in Non-Patent Document 1. FIG. When the UE 11 and UE 12 involved in ProSe communication are provided by the same eNB 19 and network coverage is available, the system 100a, as indicated by the solid arrows in FIG. 1A, the UE 11, 12, eNB 19 and EPC (Evolved Packet Core ) 14 (e.g., session management, authorization, security) can be determined to execute ProSe communication using control information exchanged. For billing, modifications are minimized with respect to the existing architecture. The UEs 11 and 12 can also exchange control signaling via the ProSe communication path as indicated by the dashed arrows in FIG. 1A.

  If the UEs 11 and 12 involved in ProSe communication are provided by different eNBs 19 and 20, and network coverage is available, the system 100b may transmit the UEs 11, 12, eNBs 19 and EPCs 14 (eg, as indicated by the solid arrows in FIG. 1B) ProSe communication using control information exchanged between session management, authorization, and security) can be determined. In this configuration, the eNBs 11 and 12 can communicate with each other via the EPC 14 or directly communicate about radio resource management, as indicated by the dashed arrows between the eNBs 11 and 12 in FIG. 1B. For billing, signaling modifications are minimized with respect to the existing architecture. The UEs 11 and 12 can also exchange control signaling via the ProSe communication path as indicated by the dashed arrows between the UEs 11 and 12 in FIG. 1B.

  If network coverage is available for a subset of UEs, one or more public safety UEs can relay radio resource management control information for other UEs that do not have network coverage.

  If network coverage is not available, the control path may exist directly between public safety UEs. In this configuration, the public safety UE relies on pre-configured radio resources to establish and maintain ProSe communications. Alternatively, a public safety radio resource management function (Public Safety Radio Resource Management Function) belonging to the public safety UE can manage allocation of radio resources for public safety ProSe communication.

  FIG. 2 is a schematic diagram illustrating an example of a system that provides a method for performing secure communication according to an embodiment of the present invention. As shown in FIG. 2, the system 10 includes UE 11, UE 12, E-UTERN 13, EPC 14, ProSe function 15, ProSe application server 16, ProSe application 17, and ProSe application 18.

  UE11 and UE12 are communicable via PC5, UE11 and E-UTERN13 communicate via LTE-Uu1, UE12 is E-UTERN13 and ProSe function 15 via LTE-Uu2 and PC3, respectively. Can communicate with. The EPC 14 and the ProSe function 15 can communicate with each other via the PC 4, the ProSe application server 16 can communicate with the EPC 14 and the ProSe application 18 via each of SG 1 and PC 1, and the ProSe function 15 via the PC 6. It can communicate by itself.

  As mentioned above, the existing key can be used when using the infrastructure, i.e. via eNodeB. However, new solutions are needed for direct discovery between devices. For example, the key is transmitted from the network to the communication partner, the key is generated between the communication partners, or a similar algorithm for negotiation can be used directly or via the network. In addition, new solutions are needed for security over unlicensed spectrum.

Two different modes for ProSe direct communication one-to-one are supported below.
Network independent direct communication: This mode of operation for ProSe direct communication is performed by using only the function and regional information to the UE and requires any network assistance to approve the connection and communication. do not do. This mode is only applicable to pre-approved ProSe-capable public safety UEs regardless of whether the UE is provided by E-UTRAN.

  Network authorized direct communication: This mode of operation for ProSe direct communication is always applicable when network assistance is always required and the only UE is “provided by E-UTRAN” for public safety UEs. is there. For non-public safety UEs, both UEs must be “provided by E-UTRAN”.

PC1:
It is a reference point between the ProSe application 18 and the ProSe application server 16 in US12. Used to define application level requirements.

PC2:
A reference point between the ProSe application server 16 and the ProSe function 15. Used to define the interrelationship between the ProSe application server 16 and the ProSe function provided by 3GPP EPS via the ProSe function 15. An example of its use may be for updating application data relating to the ProSe database in the ProSe function 15. Another example of its use may be data for use by the ProSe application server 16 in the interaction between 3GPP functions and application data, eg name translation.

PC3:
It is a reference point between the UE 12 and the ProSe function 15. Used to define the interrelationship between the UE 12 and the ProSe function 15. An example of its use is for configuration related to ProSe discovery and communication.

PC4:
A reference point between the EPC 14 and the ProSe function 15. Used to define the interrelationship between EPC 14 and ProSe function 15. The possible use case may be when establishing a one-to-one communication path between UEs or when verifying a ProSe service (approval) for real-time session management or mobility management.

PC5:
For relay and one-to-one communication (directly between UEs and between UEs on LTE-Uu) between UE11 and UE12 used for control and user plane for discovery and communication Reference point.

PC6:
This reference point is used for functions such as ProSe discovery between users subscribed to different PLMNs.

SGi:
Used for application data and application level control information exchange in addition to the related functions defined in TS 29.061 [10] via SGi.

  FIG. 3 is a schematic diagram showing a secure system according to an embodiment of the present invention. As shown in FIG. 3, the secure system 1 according to the embodiment of the present invention includes one or more requests UE_L01, an operator network_L02, and a reception UE_L03. The method of performing secure communication is performed between UEs (request UE_L01, reception UE_L03) with or without interaction with operator network_L02, secure group management L1, secure discovery L2, initial approval L3 , Authentication L4, authorization L5, security connection establishment L6, secure communication L7, and termination L8.

  Assuming network coverage is available for the UE, broadcasting is shown as an example of this embodiment. However, this embodiment also applies to multicasting and one-to-one communication as shown in FIGS. 1A, 1B and 2.

  From the group setting until the end of communication, security is required for each step as described later. Note that steps L1-L4 may be in a different order depending on the service or application.

L1: Secure group management Members can join safely, members can leave safely, and service and each member's approval level, any other required information can be modified safely.

L2: If secure discovery occurs If a discovery is not guaranteed, the device initiates communication with the wrong partner or an unauthorized device, with the result that masquerading attacks can in turn lead to fraudulent billing right. For this purpose, discovery related to communication must be guaranteed. That is, the UE authenticates the identity of other neighboring UEs. Discovery and device integrity protection should be able to authenticate messages.

L3: Initial approval Initial approval based on secure discovery leads to a determination that the discovered device belongs to a group. Thus, the next step can begin.

L4: Authentication Once a device is discovered and approved as part of a group, mutual authentication should exist, otherwise there is still scope for attack.

L5: Approval The next level of approval finds that the service can be used between devices belonging to the same group. For example, the UE is allowed to send and receive different message types and is only allowed to receive broadcasting messages.

L6: Security connection establishment (key derivation and management)
UEs belonging to the same group should have a key to protect their communication so that other UEs not belonging to the group or attacker cannot eavesdrop on or tamper with the message.

L7: Secure communication Communication between UEs in the same group may be protected by a security association with consistency and / or confidentiality depending on the subscription service type.

L8: Termination
Secure termination can provide security when the UE stops or terminates communication, or when communication of the entire group is terminated.

  Detailed methods for performing secure communications in embodiments of the present invention that meet security requirements are described in the following sections. FIG. 4 is a sequence diagram illustrating a method for performing secure communication between the UE 100 and the network 200 according to the embodiment of the present invention.

[1] Group setting and management (L1)
What is a group?
(1) Two devices (one to one) communicating with each other, or
(2) Two or more devices in which one UE can communicate with other devices (one-to-many)
(3) Two or more devices that can communicate with each other (many-to-many)
Is possible.

  Groups can be set for different communication purposes and group members can be changed. To form a group, the operator network_L02 examines the request UE_L01 requesting the receiving UE_L03 that it wants to communicate with, verifies the device if they can communicate with each other, and on both sides of the request and formation (request UE_L01 and receiving UE_L03) , Can notify the verified device.

  Hereinafter, an example of generating a group will be described. As shown in FIG. 4, the UE 100 requests a ProSe subscriber from the network 200 and creates a group (step 1). In step 1, the UE 100 needs to meet conditions, i.e. policies, e.g. interest, specific location, etc. In addition, the network 200 needs to verify whether the UE satisfies the condition, that is, the policy, for example, proximity range, subscriber, home network in the case of roaming UE, WiFi, ProSe possible, etc. The group is formed strictly, for example, the group members are whitelisted, or the group is requested by the UE 100 or by the network 200 if the network 200 recognizes all UE conditions, It is formed dynamically.

  In order to create a secure group, the UE 100 must agree to be part of the group and only the “accepted” UE 100 becomes a group member. Group management includes adding group members, deleting group members, terminating groups, and temporarily adding group members. Each UE 100 understands who is nearby from the social network application, for example, and requests for the ProSe service. The ProSe server needs to perform authorization but does not need to perform discovery.

[2] Discovery-Secure detection of UEs in proximity (L2)
The discovery and group generation in [1] occur simultaneously or are independent procedures. There are the following three means that the UE (request UE_L01) can find another UE (reception UE_L03) in the proximity. (1) broadcast base, (2) network base, and (3) device service level information base. How secure discovery is performed is described as follows.

[2-1] Broadcast-based solution There are six methods (s1-s6) in the broadcast-based solution.

(S1) Token The broadcast message may include a token that only a given UE can have. The token should be used only once to prevent the receiver from reusing it. To arrive there, the UE can calculate a token each time it receives a broadcast message, or the network can notify all of the token UEs to be used next. This can be used for such use cases as a type of service information notification, since the token can be reused by the receiver.

(S2) Signing message
The broadcast message may be signed with a key that is verified by either the receiving UE or the network to the receiving UE. Signatures can be generated by different key management solutions, or by using the current key for communication (or derivation from the current key) with the infrastructure network-a new key hierarchy is needed here obtain.

(S3) Message ID
The broadcast message can have an ID that is verified during authentication and is initially used only for authorization.

(S4) Random value The broadcast message may include random values only generated by the network and the UE. Verification of the random value is performed by the network instead of the communicating UE.

(S5) Key Each UE has a specific key belonging to another device. Therefore, it transmits a potentially long broadcast or a new type of broadcast in which the encrypted / integrity-protected parts are transmitted separately for each UE in the group.

(S6) Stamp The broadcast message can be signed with a time stamp and a lifetime. Note that the lifetime can be a very short period or can last until the next broadcast.

[2-2] Network-based solution For this purpose, the network can use the location information received from the UE (request UE_L01), and the location information can be protected by existing network security mechanisms.

[2-3] Device service level information based solution The request UE_L01 can use location information provided by a social network or other services. Security is guaranteed at the application layer.

A detailed example of discovery is described. The UE 100 can set features and / or functions that can be discovered / discovered in a D2D (inter-device communication) server.
Case 1A:
If the UE 100 does not recognize whether another UE exists in the vicinity, the UE 100 can request the ProSe server for the ProSe service. Then, the ProSe server transmits a request for the ProSe service, and at the same time, can acquire the location information of other UEs.
Case 2A:
If the UE 100 knows who is in proximity from, for example, a social network application and can inquire about the service, the ProSe server needs to perform authorization, but does not need to perform discovery.

  If the ProSe server performs the authorization, the UE 100 allows the ProSe and / or the UE 100 to be authorized to obtain a given service / communication means.

  When discovery is performed based on the proximity of the UE 100, the UE 100 transmits position information that is periodically protected by the unicast security context. The network 200 requests location information as needed or periodically. The request (step 3) is broadcast and the broadcast message requires security. The response (step 4) can be protected by a unicast security context.

  The network preserves the situation about proximity, also given by the request and receiving UE. The network 200 can broadcast to neighboring receiving UEs that are allowed to be discovered. The UE then responds to the protected message. The UE 100 notifies the network 200 of the situation and function in the initial communication and / or registration, or when any change occurs.

  A broadcast-based solution by network 200 or UE 100 requires one or more of the following requirements. That is, the receiver should be able to verify the source, the broadcast message should not be reused, and the network 200 receiving the response should be able to verify it, or if the response is too long Should be destroyed. The UE 100 can use one or more solutions to perform secure discovery. The solution includes a token, signature, message, message ID, random value, key, and stamp. These solutions are shown in FIG. 4 as follows: Step 5 (Mutual Authentication, Authentication L4), Step 6 (Approve, Authorization L5), and Step 7 (Key Generation and Algorithm Negotiation, Secure It can be used in communication L7). Steps 5 through 7 may occur together and may be relevant for broadcasting security.

[3] Initial approval (L3)
The initial approval varies depending on the discovery solution.

[3-1] Broadcast base:
Whether the request UE_L01 is allowed to communicate with the receiving UE_L03 may be examined by the network or by the receiving UE_L03 with evidence provided by the network.

[3-2] Network base:
The request UE_L01 and the receiving UE_L03 can perform mutual authentication on the direct radio interface.

[3-3] Device service level information base:
The receiving UE_L03 checks the list maintained in the UE among the members of the device group by the user or for the purpose of the ProSe service.

[4] Authentication (L4)
Once the request UE_L01 is identified as belonging to the same group, authentication is performed. Authentication can be performed locally or by interaction with the network.

[4-1] Authentication of request UE_L01:
This can be performed by the network with the request UE_L01 or the successful identification of the UE with proof from the network.

[4-2] Authentication of reception UE_L03:
This can be performed by [4-2-i] using a key shared between the request UE_L01 and the receiving UE_L03 [4-2-ii] using a current network security key or a new key [4-2-iii] A network that notifies the request UE_L01 of an input authentication request from the receiving UE_L03.

[5] Authorization-service access control (L5)
There are different levels of access control to services that the request UE_L01 and the receiving UE_L03 (hereinafter also referred to as “UE”) can use in the group.
[5-1] The UE is allowed to receive and / or transmit broadcast messages.
[5-2] The UE is allowed to receive and / or transmit multiple messages.
[5-3] The UE is allowed to receive and / or transmit messages related to one-to-one communication.
[5-4] UE approval according to subscriber information and policy UE set for ProSe service

  The network can set and provide a policy to group members including a request UE_L01 and a receiving UE_L03 according to the UE function and user contract.

  The network 200 approves the UE 100 that desires to join the group. The group member of the UE 100 verifies whether another UE is approved by the network by using the session key. Another way of performing verified authorization is (1) by a network that sends an authorization value to each UE 100 and each UE 100 uses this value to perform authorization on each other, or (2) still Another way of performing verified authorization is by sending an authorization value from the requesting UE to the receiving UE, and the receiving UE requests the network to verify this authorization value and the reception result.

[6] New key hierarchy and key management (L6)
A new key hierarchy is shown in an embodiment of the present invention. The key Kp is a key associated with the group and may also be associated with the ProSe service. It has an indicator KSI_p associated with it. Kp can be sent from the ProSe server for use.

  The keys, Kpc and Kpi are session keys derived from Kp in the UE. Kpc is a confidentiality key and Kpi is an integrity protection key. The session key is used by the UEs to perform mutual authorization and ProSe communication setup, and has direct communication between them.

  After authorization and authentication, communication devices including request UE_L01 and receive UE_L03 can initiate a session to communicate with each other. When the request UE_L01 and the receiving UE_L03 communicate with each other, they share a communication key. The key may be a unique key for each communication device, like a group key and / or a session key for each session.

  The key is managed by the network and can be transmitted over a secure communication channel with the network. Alternatively, the key can be sent to other devices including the receiving UE_L03 in communication via a secure unicast communication channel that is managed by the request UE_L01 and can be guaranteed by the network during authentication or verification. The key can also be issued by a trusted third party.

  The UEs 100 authenticate each other at the start of a session (S5). Authentication is linked with authorization (S6). 5A to 5C are schematic diagrams showing one-to-one, one-to-many, and many-to-many sessions, respectively. As shown in FIGS. 5A to 5C, UEa21 and UEa31 indicate the request UE_L01, and UEb22, UEb32, UEb33, and UEb33n indicate the reception UE_L03.

When a session is started, a session key is first generated. In the present embodiment, the request UE_L01 (UEa21, UEa31) and the reception UE_L03 (UEb22, UEb32, UEc33, UEn33n) use two types of keys including a session key.
Case 1B:
Each group has a key Kp for each service (Kp is provided as a service key), and a new session key is generated for each session.
Case 2B:
Each group has a key Kp (Kp is provided as a group key) and a new session key is generated for each session.

  In each case, either the ProSe server or the request UE_L01 sends a key. For example, the ProSe server transmits the key Kp to the request UE_L01 and the reception UE (s) L03, and the request UE_L01 transmits the session key to the reception UE_L03 (s) for each session. Alternatively, the ProSe server transmits both the key Kp and the session key to the request UE_L0 and the receiving UE (s) L03, or the request UE_L01 transmits both the key Kp and the session key to the receiving UE (s) L03. .

  Furthermore, if the group changes whether someone leaves or is added, if the session ends, or if the key times out, or if the ProSe server determines, for example, the key Kp and / or the session key Should be changed.

  When the ProSe server assigns the key Kp to the UE, the UE derives the session key from the keys for authorization and communication. The UE is preset with an algorithm for key derivation, or the key Kp is associated with KSI (key set identifier) and service. For those reasons, security issues during UE authentication and authorization or key security issues for direct communication can be solved.

  The key setting identifier (KSI) is a number associated with the encryption and integrity key derived during authentication. The key setting identifier can be sent in an authentication request message to the mobile station that is assigned by the network and stored with the calculated encryption key CK and integrity key IK. The purpose of the key setting identifier is to allow the network to identify the encryption key CK and integrity key IK stored in the mobile station without invoking the authentication process. This is used to allow reuse of the encryption key CK and the integrity key IK during subsequent connections (sessions).

[7] Secure communication (L7)
Secure communication can provide availability of message transmissions between group member UEs as well as preventing messages from being tapped or tampered with by UEs that do not belong to the group. Also, secure communication can prevent a UE from using a service that is not approved.

  Communication within the group should have integrity and / or reliability protection. All of the communications can be protected with the session key described above after the secure connection is established.

  The security policy can be negotiation and consent within the group with or without the assistance of the operator network_L02. All group members should follow the security policy.

  Next, security when a change in the location of the UE occurs will be described. If none of the UEs have a location change, there are no security issues. Furthermore, if all of the UEs do not have a changed location but remain close to each other, there are still no security issues.

  If some of the UEs (one or more UEs) are moving out of proximity from other UEs and do not use ProSe services, the group and security management needs to be updated to leave the UE in the group is there. Alternatively, if one or more UEs are moving out of proximity from the UE and wish to maintain ProSe service with each other, the group and security management needs to be updated to leave the UE within the group, and the new group And security is needed for the traveler.

  Note that the ProSe server should periodically acquire UE location information from a GMLC (Gateway Mobile Location Center) in order to compare and calculate the difference in location of all UEs.

[8] Termination (L8)
If communication is interrupted, the device should delete the session key while maintaining authentication and authorization information.

  When the communication terminates, the device can retain historical information or again an assigned token with a lifetime for the next usage time to prevent signaling for authentication and authorization.

  A smooth handover from infrastructure to direct mode will require the generation of keys between the communication parties (request UE_L01 and receive UE_L03) before the handover occurs. For example, if the communication party is using WiFi, the key should be assigned to the WiFi AP and UE. The WiFi AP and UE should authorize and authenticate each other. The key should have a limited lifetime. The network can recognize which WiFi AP the UE can communicate with. The UE can find that a WiFi AP exists and the network verifies the WiFi AP. When the UE connects to the WiFi AP, the UE authenticates the ProSe server. One option is that the ProSe function can be assigned a key to the UE for communicating with the ProSe application server.

In summary, the method for performing secure communication according to the present embodiment has the following features:
(1) The operator network_L02 determines whether or not the request UE_L01 can communicate with the reception UE_L03 requested by the request UE_L01.
(2) Security in discovery of UEs in proximity can be provided by using tokens, keys and signatures provided by the network.
(3) UE discovery security within proximity may be provided by using the location provided by the operator network_L02.
(4) Security of discovery of UEs in proximity has security provided in the application layer and can be provided by using location information provided by social network services (5) Device authorization It can be performed by the network or by device direct verification.
(6) Mutual authentication between the request UE_L01 and the receiving UE_L03 that agrees to exist in the group is performed by the network, and both UEs can be notified of the result.
(7) Mutual authentication between the request UE_L01 and the receiving UE_L03 may be performed by both ends with a key shared between them.
(8) A group key and a unique session key, and a new key for guaranteeing ProSe communication can be used.
(9) The security policy within the group for secure communication is negotiated and set.
(10) Termination management can be performed to prevent the same key from being used and set in the security context for other communications.

  According to the secure system according to the embodiment, the operator network_L02 can determine which request UE_L01 can communicate with the reception UE_L03, provide a security parameter to the request UE_L01 or the reception UE_L03, or position information of the reception UE_L03. Secure discovery can be guaranteed either by providing the request UE_L01. Moreover, the operator network_L02 can perform authentication and authorization for the request UE_L01 and the received UE_L03 and can support a security connection between the UEs to ensure ProSe communication.

[9] Detailed Method for Executing Group Management L1 Next, a more detailed method for executing group management L1 will be described. As described above, the ProSe server is a network element as agreed in 3GPP SA2 # 97 in Non-Patent Document 2. In proximity-based services, user / UE subscriber data indicates whether the UE is ProSe capable, and if so, the subscriber data is
1) Other UEs can be discovered 2) Other UEs can be discovered 3) ProSe functions of UEs that satisfy both 1) and 2) are also shown.

  Subscriber data is stored on a ProSe server that communicates with other network elements such as HSS. Depending on the operator policy, subscriber data may also be retrieved from the HSS.

The UE can be discovered and / or set a trigger event to discover and register its policy profile with the ProSe server. If there is a ProSe service request to the UE, the ProSe server can indicate the UE or discard the UE accordingly. The trigger event is as follows.
1) Place: When going to a place to receive information such as coupons,
2) VIP member: if a given UE is nearby
3) Time etc.

Upon receiving a ProSe service request from the UE, the ProSe server verifies the following before starting the discovery process.
1) Both the requesting UE and the receiving UE are ProSe capable UEs and whether they have subscribed to the ProSe service 2) Whether the requesting UE is allowed to discover the service 3) The receiving UE Is a ProSe capable UE and is allowed to be discovered, or
4) Whether the UE is allowed to have the requested service and communication.

  After verification, the ProSe server notifies the requesting UE of the received request and pending. The ProSe server must perform the discovery described above. ProSe servers can request network support for their processing. The ProSe server notifies the discovery results and includes a list of accepted UEs, authorized services, authorized communication means, and any other necessary parameters.

The requesting UE can automatically become a group administrator if none is present, and begins performing authentication, authorization and security connection establishment within the group.
There are two cases:
Case 1C: The requesting UE seeks to communicate with several UEs, but does not know whether they are in the neighborhood and / or available.
Case 2C: A requesting UE using an application indicating that some UEs are present selects some UEs with ProSe.

  Here, the details of the processing in each case will be described as follows. Note that the UE can subscribe to the same or different ProSe server.

[[Case 1C]]: The UE does not have information (knowledge) as to whether or not the receiving UE exists in the vicinity.
FIG. 6 is a flowchart illustrating a method for performing group management in case 1C according to the embodiment. As illustrated in FIG. 6, the system includes a UE a 21 that provides a service as a request UE, a UE b 22 that provides a service as a receiving UE, a ProSe server 24, and an HSS 25. The method includes the following nine steps SP1 to SP9.

SP1: The ProSe server 24 stores UE subscriber data.
SP2: Request UE 21 is optional if ID of request UE, list of IDs of receiving UE, request service type, request communication type, group previously formed or requesting UE wants to name group ID The ProSe service request is transmitted to the ProSe server 24 including the group ID and the arbitrary range.
SP3: The ProSe server 24 can mutually communicate with the HSS 25 about the authentication information of the UE if necessary. SP4: The ProSe server 24 performs verification in the request UE 21 and the reception UE 22.
SP5: The ProSe server 24 sends a ProSe service ACK to the requesting UE 21 including the pending status.
SP6: The ProSe server 24 performs a discovery process.
SP7: After the discovery process, the ProSe server 24 transmits a ProSe service result having the group ID, the receiving UE, the permitted service type, the permitted communication type, and the security parameter (arbitrary) to the request UE 21.
SP8: The ProSe server 24 also transmits the same ProSe service result to the receiving UE 22.
SP9: Once the requesting UE 21 and the receiving UE 22 recognize an authorized group member, group security establishment is started.

[[Case 2C]]: The UE recognizes that some other UE is nearby.
In this case 2C, it is assumed that the subscriber runs an application that indicates which UEs are in proximity. The subscriber can select which UE wants to have ProSe service. Therefore, no discovery process is required. The ProSe server 24 will verify whether the requesting UE 21 has a ProSe service with the receiving UE 22 in the same way as described in case 1C.

In summary, the method for performing secure group management according to the present embodiment has the following features:
(1) The ProSe server is configured with UE subscriber data including the UE function of the ProSe service, the information of the UE having the ProSe service, and the policy set by the UE.
(2) In order to verify whether the ProSe server has requested a ProSe service using the communication type and whether the requesting UE has a ProSe service using an existing receiving UE, Approve.
(3) The ProSe server approves the receiving UE to verify whether they have a ProSe service using the requested UE.
(4) UE can discover using network authorization and set event trigger to be discovered.
(5) The ProSe server sends a ProSe service ACK to the requesting UE using the pending status.
(6) The ProSe server also transmits the ProSe service result to the requesting UE and the receiving UE having the group ID, the receiving UE, the permitted service type, the communication type, and the security parameter (arbitrary).

  According to the secure system according to the embodiment of the present invention, the network controls whether the requesting and receiving UEs have the ProSe service result with each other. The requesting UE can select a receiving UE that wants the requesting UE to have a ProSe service and requests the network to approve. Moreover, requesting and receiving UEs can discover and set event triggers to be discovered so that they can have customized settings.

The program can be stored and supplied to a computer using various types of non-transitory computer readable media.
Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (for example, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (for example, magneto-optical disks), CD-ROM (Read Only Memory), CD-R ( compact disc recordable), CD-R / W (compact disc rewritable), semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory)). The program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. Transient computer readable media can be used to provide the program to a computer via a wired communication path (such as electrical wires and optical fibers) or a wireless communication path.

  This application claims the benefit of priority from Japanese Patent Application No. 2013-137291 filed on June 28, 2013, the disclosure of which is incorporated herein by reference in its entirety. The

1 secure system 10 system 11 UE
12 UE
13 E-UTERN
14 EPC
15 ProSe function 16 ProSe APP server 17 ProSe APP
18 ProSe APP
19 eNB
20 eNB
21 UEa
22 UEb
24 ProSe server 25 HSS
31 UEa
32 UEb
33 UEc
33n UEn
100 UE
100a system 100b system 200 network L01 request UE
L02 Operator network L03 Receiving UE
L1 Secure Group Management L2 Secure Discovery L3 Initial Authorization L4 Authentication L5 Authorization L6 Security Connection Establishment L7 Secure Communication L8 Termination

Claims (8)

A method for forming a secure group in proximity-based service (Proximity based Service (ProSe)) communication by a requesting device that requests communication and a receiving device that receives a communication request from the requesting device,
The request and receiving device is subscribed to ProSe,
The method
Request a service request from the requesting device to the ProSe server;
The service request includes a request to communicate with the receiving device from the requesting device;
Verification of the request and receiving device by the ProSe server,
Sending the ProSe service result to the request and receiving device to notify that the group member is authorized,
Initiating group security establishment of the group including the request and receiving device;
Including that. The service request includes a request device ID, a list of receiving devices, a request service type, and a request communication type.
The method for forming a secure group in ProSe communication according to claim 1. The requesting device obtains location information of the receiving device when the receiving device is within a predetermined area from the requesting device and / or does not know whether it is available for the communication In order to do the discovery process by the ProSe server,
The method for forming a secure group in ProSe communication according to claim 1 or 2, further comprising: Performing the discovery includes whether the requesting device and the receiving device are both ProSe-capable devices, whether the requesting device is allowed to discover services, and whether the receiving device is a ProSe-capable device. Verifying whether it is allowed to be discovered and whether the request and receiving device are allowed to have the requested service and the requested communication according to the service request;
The method for forming a secure group in ProSe communication according to claim 3. The request and subscription data of the receiving device are stored in the ProSe server and / or other servers accessed from the ProSe server,
The formation method of the secure group in the ProSe communication of any one of Claims 1 thru | or 4. The subscription data indicates whether the requesting device is enabled for ProSe;
Being ProSe enabled indicates the request and the ProSe function of the receiving device,
The functionality includes whether the device can discover other devices and / or whether the device can be discovered by other devices,
The method for forming a secure group in ProSe communication according to claim 5. Further comprising setting a trigger event to be discovered and / or discovered and registering the policy profile with the ProSe server;
The triggering event is triggered when the requesting and / or receiving device moves to any location or area, a specific device approaches, approaches and reaches a predetermined distance from the requesting and / or receiving device. 5. The method for forming a secure group in ProSe communication according to claim 3 or 4, wherein one or more cases of arriving. A secure system comprising a plurality of user equipment (User Equipments (UEs)) and a proximity-based service (Proximity based Service (ProSe)) server,
A requesting device requesting communication; and
A receiving device for receiving a communication request from the requesting device,
The requesting device and the receiving device are subscribed to a ProSe service;
The requesting device requests a service request from the ProSe server, the service request including a request for communicating with the receiving device from the requesting device;
The ProSe server verifies the request and receiving device,
The ProSe server sends a ProSe service result to the request and receiving device to notify that group members are allowed,
The requesting and receiving device initiates group security establishment for the group that includes the requesting and receiving device.

Images