[DESCRIPTION]
[Title of Invention]
SECURE GROUP CREATION IN PROXIMITY BASED SERVICE
COMMUNICATION
5
[Technical Field]
[0001]
This invention relates to a secure system and a method of forming a secure group, and
more specifically, to a secure system that provides a method of forming a secure group in
10 Proximity based Service (ProSe) communication.
[Background Art]
[0002]
3GPP (3rd Generation Partnership Project) has started to study Proximity based
15 Services (ProSe) for both commercial and public safety uses. 3GPP SA1 (Services Working
Group) has initiated some security requirements for secure communication, UE (User
Equipment) identity, and privacy protection.
[0003]
ProSe represents a recent and enormous socio-technological trend. The principle of
20 these applications is to discover instances of the applications running in devices that are within
proximity of each other, and ultimately to also exchange application-related data. In parallel to
this, there is interest in proximity-based discovery and communications in the public safety
community.
[0004]
25 ProSe communication can provide services to the UEs in proximity via an eNB
(Evolved Node B) or without the eNB. The SA1 requires that the ProSe service be provided to
UEs with or without network coverage. The UEs can discover other nearby UEs or be
discovered by other UEs, and they can communicate with each other. Some use cases can be
found in NPL 1. The ProSe server is a network element as agreed in 3GPP SA2#97 to NPL 2.
30
[Citation List]
[Non Patent Literature]
[0005]
NPL 1: 3GPP TR 22.803 Feasibility study for Proximity Services (ProSe), (Release 12)
2
NPL 2: 3GPP TR 23.703 Study on architecture enhancements to support Proximity Services
(ProSe) (Release 12)
[Summary of Invention]
[Technical Problem5 ]
[0006]
However, despite the security issues involving authorization as well as privacy issues,
3GPP SA3 offers no security solution.
10 [Solution to Problem]
[0007]
The present invention has been made to present an overall security solution for the
above-mentioned security issues.
[0008]
15 In one embodiment, there is provided a method of forming a secure group in Proximity
based Service (ProSe) communication by a requesting device which requests a communication
and a receiving device which receives a communication request from the requesting device,
wherein the requesting and receiving devices have subscribed ProSe service, the method
including requesting a service request to a ProSe server from the requesting device, the service
20 request indicating a request to communicate with the receiving device from the requesting device,
performing verification on the requesting and receiving devices by the ProSe server, sending a
ProSe Service result to the requesting and receiving devices to inform to be allowed a group
member, and starting a group security establishment of the group including the requesting and
receiving devices.
25 [0009]
In another embodiment, there is provided a secure system including a plurality of User
Equipments (UEs) and a Proximity based Service (ProSe) server, including a requesting device
which requests a communication; and a receiving device which receives a communication
request from the requesting device. The requesting device and the receiving device have
30 subscribed ProSe service. The requesting device requests a service request to the ProSe server,
the service request indicating a request to communicate with the receiving device from the
requesting device. The ProSe server performs verification on the requesting and receiving
devices. The ProSe server sends a ProSe Service result to the requesting and receiving devices
to inform to be allowed a group member. The requesting and receiving devices start a group
3
security establishment of the group including the requesting and receiving devices.
[Advantageous Effects of Invention]
[0010]
A secure system and a method of forming a secure group in Proximity based Servic5 e
(ProSe) communication can present solutions for security issues.
[Brief Description of Drawings]
[0011]
10 The above and other objects, advantages and features of the present invention will be
more apparent from the following description of certain preferred embodiments taken in
conjunction with the accompanying drawings, in which:
[Fig. 1A]
Fig. 1A is a schematic view showing the ProSe Communication scenario in NPL 1;
15 [Fig. 1B]
Fig. 1B is a schematic view showing the ProSe Communication scenario in NPL 1;
[Fig. 2]
Fig. 2 is a schematic view showing an example of the systems which provide a method
of making a secure communication according to an exemplary embodiment of the present
20 invention;
[Fig. 3]
Fig. 3 is a schematic view showing a secure system of an exemplary embodiment of the
present invention;
[Fig. 4]
25 Fig. 4 is a sequence diagram explaining a method of making a secure communication of
an exemplary embodiment of the invention;
[Fig. 5A]
Fig. 5A is a schematic view showing a One-to-one session;
[Fig. 5B]
30 Fig. 5B is a schematic view showing a One-to-many session; and
[Fig. 5C]
Fig. 5C is a schematic view showing a Many-to-many session.
[Fig. 6]
Fig. 6 is a flow chart showing a method of performing the group management of a case
4
1C of an exemplary embodiment.
[Description of Embodiments]
[0012]
For purposes of the description hereinafter, the terms “upper”, “lower”, “right”, “5 left”,
“vertical”, “horizontal”, “top”, “bottom”, “lateral”, “longitudinal”, and derivatives thereof shall
relate to the invention as it is oriented in the drawing figures. However, it is to be understood
that the invention may assume alternative variations and step sequences, except where expressly
specified to the contrary. It is also to be understood that the specific devices and processes
10 illustrated in the attached drawings, and described in the following specification, are simply
exemplary embodiments of the invention. Hence, specific dimensions and other physical
characteristics related to exemplary embodiments disclosed herein are not to be considered as
limiting.
[0013]
15 In the exemplary embodiments, though the security solutions with a focus on
specifically direct communication, discovery, and communication will be explained, the
solutions can be applied to other communications as well.
[0014]
Firstly, definitions given in 3GPP TR 21.905: "Vocabulary for 3GPP Specifications" will
20 be explained.
[0015]
ProSe Direct Communication:
A communication between two or more UEs in proximity that are ProSe-enabled, by
means of user plane transmission using E-UTRA technology via a path not traversing any
25 network node.
[0016]
ProSe-enabled UE:
A UE that supports ProSe requirements and associated procedures. Unless explicitly
stated otherwise, a Prose-enabled UE refers both to a non-public safety UE and a public safety
30 UE.
[0017]
ProSe-enabled Public Safety UE:
A ProSe-enabled UE that also supports ProSe procedures and capabilities specific to
Public Safety.
5
[0018]
ProSe-enabled non-public safety UE:
A UE that supports ProSe procedures but not capabilities specific to public safety.
[0019]
ProSe Direct Discovery5 :
A procedure employed by a ProSe-enabled UE to discover other ProSe-enabled UEs in
its vicinity by using only the capabilities of the two UEs with rel.12 E-UTRA technology.
[0020]
EPC-level ProSe Discovery:
10 a process by which the EPC determines the proximity of two ProSe-enabled UEs and
informs them of their proximity.
[0021]
Figs. 1A and 1B are schematic views showing the ProSe Communication scenarios in
NPL 1. When a UE 11 and a UE 12 which are involved in the ProSe Communication are
15 served by the same eNB 19 and network coverage is available, a system 100a can decide to
perform ProSe Communication using control information exchanged between the UEs 11, 12,
eNB 19 and an EPC (Evolved Packet Core) 14 (e.g., session management, authorization,
security) as shown by the solid arrows in Fig. 1A. For charging, modifications should be
minimized with respect to the existing architecture. The UEs 11 and 12 can in addition
20 exchange control signaling via the ProSe Communication path as shown by the dashed arrow in
Fig. 1A.
[0022]
When the UEs 11 and 12 involved in the ProSe Communication are served by different
eNBs 19, 20 and network coverage is available, a system 100b can decide to perform ProSe
25 Communication using control information exchanged between the UEs 11, 12, eNB 19 and the
EPC 14 (e.g., session management, authorization, security) as shown by the solid arrows in Fig.
1B. In this configuration, the eNBs 11 and 12 may coordinate with each other through the EPC
14 or communicate directly for radio resource management as shown by the dashed arrow
between the eNBs 11 and 12 in Fig. 1B. For charging, signaling modifications should be
30 minimized with respect to the existing architecture. The UEs 11 and 12 can in addition
exchange control signaling via the ProSe Communication path as shown by the dashed arrow
between the UE 11 and the UE 12 in Fig. 1B.
[0023]
If network coverage is available for a subset of the UEs, one or more Public Safety UEs
6
may relay the radio resource management control information for other UEs that do not have
network coverage.
[0024]
If network coverage is not available, the control path can exist directly between Public
Safety UEs. In this configuration, the Public Safety UEs can rely on pre-configured 5 radio
resources to establish and maintain the ProSe Communication. Alternatively, a Public Safety
Radio Resource Management Function, which can reside in a Public Safety UE, can manage the
allocation of radio resources for Public Safety ProSe Communication.
[0025]
10 Fig. 2 is a schematic view showing an example of the systems which provide a method
of making a secure communication according to an exemplary embodiment of the present
invention. As shown in Fig. 2, a system 10 includes the UE 11, the UE 12, an E-UTERN 13,
the EPC 14, a ProSe Function 15, a ProSe APP Server 16, a ProSe APP 17, and a ProSe APP 18.
[0026]
15 The UE 11 and the UE 12 can communicate through a PC5, the UE 11 and the
E-UTERN 13 communicate through LTE-Uu1, and the UE 12 can communicate with the
E-UTERN 13 and the ProSe Function 15 through LTE-Uu2 and a PC3, respectively. The EPC
14 and the ProSe Function 15 can communicate through a PC4, the ProSe APP server 16 can
communicate with the EPC 14 and the ProSe APP 18 through a SG1 and a PC1, respectively, and
20 the ProSe Function 15 can communicate by itself through a PC6.
[0027]
As described above, existing keys can be used when using an infrastructure, i.e., via
eNodeB. However, a new solution is needed for device-to-device direct discovery and
communication; for example, a key can be sent from the network to communicating parties, a
25 key can be created between communicating parties, or a similar algorithm for negotiation can be
used directly or via the network. Further, a new solution is also needed for the security over the
unlicensed spectrum.
[0028]
Two different modes for ProSe Direct Communication one-to-one are supported:
30 Network independent direct communication: This mode of operation for ProSe Direct
Communication does not require any network assistance to authorize the connection and
communication is performed by using only functionality and information local to the UE. This
mode is applicable only to pre-authorized ProSe-enabled Public Safety UEs, regardless of
whether the UEs are served by E-UTRAN or not.
7
[0029]
Network authorized direct communication: This mode of operation for ProSe Direct
Communication always requires network assistance and may also be applicable when only one
UE is "served by E-UTRAN" for Public safety UEs. For non-Public Safety UEs both UEs must
be "served by E-UTRAN"5 .
[0030]
PC1:
It is the reference point between the ProSe application 18 in the UE 12 and in the ProSe
App Server 16. It is used to define application level requirements.
10 [0031]
PC2:
It is the reference point between the ProSe App Server 16 and the ProSe Function 15.
It is used to define the interaction between the ProSe App Server 16 and ProSe functionality
provided by the 3GPP EPS via the ProSe Function 15. One example of use of it may be for
15 application data updates for a ProSe database in the ProSe Function 15. Another example of
use of it may be data for use by the ProSe App Server 16 in interworking between 3GPP
functionality and application data, e.g. name translation.
[0032]
PC3:
20 It is the reference point between the UE 12 and the ProSe Function 15. It is used to
define the interaction between the UE 12 and the ProSe Function 15. An example of use of it is
for configuration for ProSe discovery and communication.
[0033]
PC4:
25 It is the reference point between the EPC 14 and the ProSe Function 15. It is used to
define the interaction between the EPC 14 and the ProSe Function 15. Possible use cases of it
may be when setting up a one-to-one communication path between UEs or when validating
ProSe services (authorization) for session management or mobility management in real time.
[0034]
30 PC5:
It is the reference point between the UE 11 to the UE 12 used for control and user plane
for discovery and communication, for relay and one-to-one communication (between UEs
directly and between UEs over LTE-Uu).
[0035]
8
PC6:
This reference point may be used for functions such as ProSe Discovery between users
which are subscribed to different PLMNs.
[0036]
S5 Gi:
In addition to the relevant functions defined in TS 29.061 [10] via SGi, it may be used
for application data and application level control information exchange.
[0037]
Fig. 3 is a schematic view showing a secure system of an exemplary embodiment of the
10 present invention. As shown in Fig. 3, a secure system 1 of an exemplary embodiment of the
present invention includes one or more requesting UEs L01, an operator network L02, and one or
more receiving UEs L03. A method of performing a secure communication includes steps of a
secure group management L1, a secure discovery L2, an initial authorization L3, an
authentication L4, an authorization L5, a security association establishment L6, a secure
15 communication L7, and a termination L8, which are performed between UEs (the requesting UE
L01, the receiving UE L03) with or without interacting with the operator network L02.
[0038]
Assuming that the network coverage is available for UEs, broadcasting is presented as
an example in this exemplary embodiment, but this exemplary embodiment also applies to
20 multiple-casting and one-to-one communications as shown in Figs. 1A, 1B, and 2.
[0039]
From setting up of a group till communication termination, security is needed in each
step as described below. Note that steps L1 - L 4 can be in a different order depending on the
service or application.
25 [0040]
L1: Secure group management
Members can join securely, members can leave securely, and an authorization level of
service and each of the members, and any other required information can be modified securely.
[0041]
30 L2: Secure discovery should happen
If discovery is not secured, a device may start communication with a wrong party or a
rogue device, with the result that masquerading attacks can happen that in turn could lead to
fraudulent charging. For this purpose, the discovery related communication must be secured,
i.e., a UE authenticates identity of other UEs in proximity; integrity protection for discovery
9
and a device should be able to authenticate the message.
[0042]
L3: Initial Authorization
The initial authorization based on secure discovery will lead to the decision that the
discovered device belongs to the group, and thus the next step can sta5 rt.
[0043]
L4: Authentication
Once the device is discovered and authorized as a part of the group, there should be a
mutual authentication; otherwise there is still a scope of attacks.
10 [0044]
L5: Authorization
The next level of authorization will find out what services can be used between the
devices which belong to the same group. For example, a UE is allowed to send and receive
different types of messages or is only allowed to receive broadcasting messages.
15 [0045]
L6: Security association establishment (Key derivation and management)
The UEs which belong to the same group should have keys to protect their
communication such that other UEs which do not belong to the group or an attacker cannot
eavesdrop or alter the messages.
20 [0046]
L7: Secure communication
The communication between UEs in the same group can be protected by the security
association, with integrity and/or confidentiality protection according to the subscription service
type.
25 [0047]
L8: Termination
The secure termination can provide security when UE(s) suspend or terminate the
communication, or when the entire group communication is terminated.
[0048]
30 The detailed method of performing a secure communication of an exemplary
embodiment of the invention that fulfills the security requirements will be explained in the
following sections. Fig. 4 is a sequence diagram explaining a method of making a secure
communication between UE 100 and network 200 of an exemplary embodiment of the
invention.
10
[0049]
[1] Group setting and management (L1)
A group can be
(1) two devices communicating with each other (one-to-one), or
(2) more than two devices (one-to-many) where one UE can communicate with the 5 other
devices.
(3) more than two devices (many-to-many) that can communicate with each other.
[0050]
A group can be set up for different communication purposes, and group members can be
10 changed. To form a group, the operator network L02 can check the requesting UE L01 which
requests the UE L03 which it wants to communicate with, verify devices if they can
communicate with each other, and inform the verified devices at both sides (the requesting UE
L01 and the receiving UE L03) of the request and formation.
[0051]
15 Hereinafter one example of creating a group will be explained. As shown in Fig. 4, a
UE 100 requests ProSe subscription to a network 200 and creates a group (Step 1). In step 1,
the UE 100 needs to meet conditions, that is policy, e.g. interest, specific location etc. Also the
network 200 needs to verify whether UE meets conditions, that is policy, e.g. proximity range,
subscription, home network in case of roaming UE, WiFi or not, ProSe enabled, etc. The group
20 is strictly formed, for example, the members of the group should be registered in a whitelist, or
the group is dynamically formed on a request from the UE 100, or by the network 200 if the
network 200 knows all UE conditions.
[0052]
For creating a secure group, UEs 100 must agree to be a part of the group, and only
25 “agreed” UEs 100 become group members. A group management includes adding group
members, removing group members, ending the group, and adding temporary group members.
Each UE 100 can see who is in proximity from e.g. a social network application, and requests for
ProSe service, and the ProSe server needs to perform the authorization, but does not have to
perform discovery.
30 [0053]
[2] Discovery - Secure detection of UEs in proximity (L2)
Discovery and group creation in [1] can happen at the same time or be independent
procedure.
There can be following three means that a UE (the requesting UE L01) can discover
11
other UEs (the receiving UEs L03) in proximity: (1) Broadcast based, (2) Network based, and (3)
Device service level information based. How secure discovery can be done will be described as
follows.
[0054]
[2-1] Broadcast based soluti5 on
There are six ways (s1 - s6) in Broadcast based solution:
[0055]
(s1) Token
The broadcast message can contain a token that only the given UEs can have. The
10 token should be used only once to prevent the receiving side from reusing it. In order to reach
that, the UEs can calculate a token each time on receiving the broadcast message, or the network
can inform all the UEs of the token to be used next. This can be used for such a use case as an
information notification kind of service, since the token can be reused by the receiving side.
[0056]
15 (s2) Signing message
The broadcast message can be signed by a key that can be verified either by the
receiving UEs or by the network for the receiving UEs. Signing can happen by different key
management solutions or it can happen using the current keys for communicating with the
infrastructure network (or derivation from current keys) – a new key hierarchy might be needed
20 here.
[0057]
(s3) Message ID
The broadcast message can have an ID that can be verified during the authentication and
is used initially only for authorization.
25 [0058]
(s4) Random value
The broadcast message can contain a random value that can only be generated by the
network and UE. Verification of the random value is done by the network on behalf of
communicating UEs.
30 [0059]
(s5) Key
Each UE has a specific key belonging to other devices, and thus it sends a potentially
long broadcast or a new type of broadcast that is sent in pieces with encrypted / integrity
protected parts for each UE in the group.
12
[0060]
(s6) Stamp
The broadcast message can be signed with time-stamp and life-time. Note that this
life-time can be a very short period or can last until the next broadcast.
[5 0061]
[2-2] Network based solution
A network can provide information. For this purpose, the network can use the location
information received from the UE (the requesting UE L01), and the location information can be
protected by the existing network security mechanism.
10 [0062]
[2-3] Device service level information based solution
The requesting UE L01 can use location information provided by a social network or
other services. Security can be ensured in an application layer.
[0063]
15 Detailed examples of the discovery will be explained. The UE 100 can set features
and/or capabilities of Discovery/Discoverable in D2D (device-to-device communication) server.
Case 1A:
If the UE 100 does not know whether the other UEs are in proximity, the UE 100 can
request the ProSe server for the ProSe service, and the ProSe server can send out the request for
20 the ProSe service and meanwhile get the other UEs location information.
Case 2A:
If the UE 100 can see who is in proximity from e.g. a social network application, and
asks for service, the ProSe server needs to perform the authorization but does not have to
perform Discovery.
25 [0064]
If the ProSe server performs the authorization, the UEs 100 enable the ProSe and/or
UEs 100 to be allowed to get given service/communication means.
[0065]
If the discovery is done based on the proximity of UEs 100, the UE 100 sends location
30 information periodically protected by a unicast security context. The network 200 requests
location information when needed or periodically. The request (step 3) can be broadcasted, and
the broadcasted message requires security. The response (step 4) can be protected by the
unicast security context.
[0066]
13
The Network stores the conditions for proximity, which can also be given by the
requesting and receiving UE. The network 200 can broadcast to the receiving UEs in a
neighborhood which are allowed to be discovered, and the UEs respond with protected messages.
The UE 100 informs the network 200 of its conditions and capabilities at a first communication
and/or registration or when any change happe5 ns.
[0067]
The broadcast based solutions by the network 200 or the UE 100 require one or more of
the following requirements. That is, the receiving side should be able to verify the source, the
broadcast message should not be re-used, the network 200 which receives the response should be
10 able to verify it, or the response should be discarded if it is too long. The UE 100 can use one
or more of solutions for performing secure discovery. The solutions include a token, a sign, a
message, a message ID, a random value, keys, and stamps. Note that those solutions can be
used in the step 5 (mutually authenticate, the authentication L4), in the step 6 (authorize, the
authorization L5), and in the step 7 (generate keys and negotiate algorithm, the secure
15 communication L7), as shown in Fig. 4. The steps 5 to 7 can happen together, and might be
related to broadcast security.
[0068]
[3] Initial Authorization (L3)
The initial authorization varies according to the above discovery solution.
20 [0069]
[3-1] Broadcast based:
Whether the requesting UE L01 is allowed to communicate with the receiving UE L03
can be checked by a network or by the receiving UE L03 having a proof provided by the
network.
25 [0070]
[3-2] Network based:
The requesting UE L01 and the receiving UE L03 can perform a mutual authentication
over the direct wireless interface.
[0071]
30 [3-3] Device service level information based:
The receiving UE L03 checks a list maintained by the user or in a UE among the
members of the group of devices for ProSe service purpose.
[0072]
[4] Authentication (L4)
14
Once the requesting UE L01 is identified as belonging to the same group, then
authentication takes place. Authentication can be carried out locally or by interacting with the
network.
[0073]
[4-1] Authentication of the requesting UE L5 01:
This can be performed by successful identification of the requesting UE L01 by a
network or a UE with a proof from a network.
[0074]
[4-2] Authentication of the receiving UE L03:
10 This can be performed by
[4-2-i] using a key shared between the requesting UE L01 and the receiving UE L03
[4-2-ii] using current network security keys or new keys
[4-2-iii] a network which informs the requesting UE L01 of the incoming authentication request
from the receiving UE L03.
15 [0075]
[5]Authorization – service access control (L5)
There should be different levels for access control to services that the requesting UE
L01 and the receiving UE L03 (hereinafter also referred to as “UE”) can use within the group.
[5-1]UE is allowed to receive and/or send a broadcasting message.
20 [5-2]UE is allowed to receive and/or send multiple messages.
[5-3]UE is allowed to receive and/or send a message for one-to-one communications.
[5-4] UE authorization according to subscription information and the policy UE set for ProSe
service.
[0076]
25 A network can set up and provide the policy to the group members including the
requesting UE L01 and the receiving UE L03 according to UE capabilities and user
subscriptions.
[0077]
The network 200 performs authorization for the UEs 100 want to join the group. The
30 group member of UEs 100 verify whether other UEs are authorized by the network by using the
session keys. Another method for performing validated authorization is done by (1) a network
sending an authorization value to each UE 100, and each UE 100 uses this value to perform
authorization for each other, or (2) Yet another method for performing a validated authorization
is done by sending an authorization value from a requesting UE to a receiving UE, and then the
15
receiving UE requests the Network to validate this authorization value and receiving result.
[0078]
[6] New key hierarchy and key management (L6)
A new key hierarchy is presented in this exemplary embodiment of the invention. Key
Kp is a key related to the group and also may related to a ProSe service. It has an indica5 tor
KSI_p related to it. Kp can be sent from ProSe Server to use.
[0079]
Keys, Kpc and Kpi are session keys that are derived from Kp at UEs. Kpc is a
confidentiality key and Kpi is an integrity protection key. The session keys are used for UE to
10 perform authorization for each other, and ProSe communication setup, and have the direct
communication between them.
[0080]
After authorization and authentication, the communicating devices including the
requesting UE L01 and the receiving UE L03 can start sessions to communicate with each other.
15 When the requesting UE L01 and the receiving UE L03 communicate with each other, they
should share communication keys. The keys can be a group key, and/or a unique key per
communicating device as well as a session key per each session.
[0081]
The key can be managed by the network and sent over the secure communication
20 channel with the network. Alternatively, the key can be managed by the requesting UE L01
and sent to other devices including the receiving UE L03 in the communication, over a secure
unicast communication channel that can be secured by the network during authentication or
verification. The key can also be issued by a third trusted party.
[0082]
25 The UEs 100 authenticate each other at the beginning of a session (S5). The
authentication is linked to authorization (S6). Figs. 5A to 5C are schematic views showing
One-to-one, One-to-many, and Many-to-many sessions, respectively. As shown in Figs. 5A to
5C, a UEa 21 and a UEa 31 indicate the requesting UE L01, and a UEb 22, a UEb 32, a UEc 33
and a UEn_33n indicate the receiving UE L03.
30 [0083]
When the session is started, firstly session keys are generated. In this exemplary
embodiment, the requesting UE L01 (UEa 21, the UEa 31) and the receiving UE L03 (UEb 22,
the UEb 32, the UEc 33, the UEn_33n) use two kinds of keys including session keys.
Case 1B:
16
Each group has a key Kp for each service (Kp is served as a service key) and a new
session key is created for each session.
Case 2B:
Each group has the key Kp (Kp is served as a group key), and a new session key is
created for each sessi5 on.
[0084]
In each case, either the ProSe server or the requesting UE L01 sends keys. For
example, the ProSe server sends the key Kp to the requesting UE L01 and the receiving UE(s)
L03, and the requesting UE L01 sends a session key to the receiving UE(s) L03 every session.
10 Alternatively, the ProSe server sends both of the key Kp and the session key to the requesting
UE L0 and the receiving UE(s) L03, or the requesting UE L01 sends both of the key Kp and the
session key to the receiving UE(s) L03.
[0085]
Further, when the group changes if someone leaves or is added, when a session ends or
15 a key times out, or when the ProSe server has made a decision, for example, the key Kp and/or
the session key should be changed.
[0086]
If the ProSe Server allocates the key Kp to UEs, UEs derive session keys from that for
authorization and communication. UEs can be pre-configured with algorithms for key
20 derivation, or the key Kp is related to a KSI (key set identifier) and a service. Because of them,
the security problems during UEs’ authentication and authorization or the security problems of a
key for direct communication may be solved.
[0087]
Note that the key set identifier (KSI) is a number which is associated with the cipher
25 and integrity keys derived during the authentication. The key set identifier can be allocated by
the network and sent with the authentication request message to the mobile station where it is
stored together with a calculated cipher key CK and an integrity key IK. The purpose of the
key set identifier is to make it possible for the network to identify the cipher key CK and
integrity key IK which are stored in the mobile station without invoking the authentication
30 procedure. This is used to allow re-use of the cipher key CK and integrity key IK during
subsequent connections (session).
[0088]
[7] Secure Communication (L7)
Secure communication can provide message transmission availability between group
17
member UEs, as well as preventing a message from being eavesdropped on or altered by UEs
that do not belong to the group. Also the secure communication can prevent UE from using an
unauthorized service.
[0089]
The communication within the group should have integrity and/or confidentialit5 y
protection. All the communications can be protected by the session keys described above, after
the security association is established.
[0090]
The security policy can be a negotiation and an agreement within the group with or
10 without the support of the operator network L02. All the group members should follow the
security policy.
[0091]
Next, the security in the case where UEs’ location change happens will be explained.
If none of UEs has a location change, there is no security issue. Further, if all of the UEs have a
15 changed location, but stayed in proximity to each other, then there is still no security issue.
[0092]
If a part of UEs (one or more UEs) have moved out of proximity from other UEs and
they do not use the ProSe service, group and security management need to be updated for the
remaining UEs in the group. Alternatively, if one or more UEs have moved out of proximity
20 from the UEs and they want to keep the ProSe service with each other, group and security
management need to be updated for the remaining UEs in the group, and a new group and
security are needed for the traveler.
[0093]
Note that the ProSe Server should get UE location information from GMLC (Gateway
25 Mobile Location Center) periodically, to compare and compute the location differences of all
UEs.
[0094]
[8] Termination (L8)
When the communication is to be suspended, devices should remove the session key
30 while keeping information of the authentication and authorization.
[0095]
When the communication is to be terminated, the devices can keep history information,
or the allocated token with a lifetime for the next use time to prevent signaling for authentication
and authorization again.
18
[0096]
Smooth handover from an infrastructure to a direct mode will require creation of a key
between communicating parties (the requesting UE L01 and the receiving UE L03) before a
handover happens. For example, if communicating parties are using WiFi, a key should be
allocated to WiFi AP and UEs. The WiFi AP and UEs should authorize and authenticate eac5 h
other. The key should have a limited life-time. A network can recognize which WiFi AP the
UE can communicate with. UEs can find that there is a WiFi AP nearby and the network
verifies the WiFi AP. UEs authenticate with the ProSe Server when UEs connect to a WiFi AP.
One option is that the ProSe Function can allocate keys for the UEs to communicate with a
10 ProSe APP Server.
[0097]
To summarize the above description, the method of making a secure communication of
an exemplary embodiment includes the following features:
(1) The operator network L02 determines whether the requesting UE L01 can communicate with
15 the receiving UE L03 requested by the requesting UE L01.
(2) Security in discovery of UEs in proximity can be provided by using a token, a key, and
signing provided by the network.
(3) Security in discovery of UEs in proximity can be provided by using a location provided by
the operator network L02.
20 (4) Security in discovery of UEs in proximity can be provided by using location information
provided by social network services, with security provided in an application layer.
(5) Authorization of the devices can be performed by the network or by devices direct
verification.
(6) Mutual authentication between the requesting UE L01 and the receiving UEs that agreed to
25 be in the group L03 can be carried out by the network and also both UEs can be informed with
the result.
(7) Mutual authentication between the requesting UE L01 and the receiving UEs L03 can be
carried out by both ends with a key shared there between.
(8) New keys for securing the ProSe communication which are a group key and a unique session
30 key can be used.
(9) Security policy in a group for secure communication is negotiated and set.
(10) Termination management can be performed to prevent the same keys from being used and
set up a security context for other communication.
[0098]
19
According to the secure system of an exemplary embodiment, the operator network L02
can determine the receiving UE(s) L03 with which the requesting UE L01 can communicate, and
can ensure secure discovery by either providing security parameters to the requesting UE L01 or
receiving UE L03, and providing location information of the receiving UE L03 to the requesting
UE L01. Furthermore, the operator network L02 can perform authentication and authorizati5 on
for the requesting UE L01 and receiving UE L03, and can support security association between
UEs to secure ProSe communication.
[0099]
[9] A detailed method of performing the group management L1
10 Next, a more detailed method of performing the group management L1 will be
explained. As described above, the ProSe server is a network element as agreed in 3GPP
SA2#97 to NPL2. In Proximity-based services, the subscription data of a user/UE indicates
whether a UE is ProSe enabled, and if it is so, the subscription data also indicates the UE’s ProSe
capability which:
15 1) can discover other UEs;
2) can be discovered by other UEs; or
3) satisfies both of 1) and 2).
[0100]
The subscription data is stored in a ProSe server that interacts with other network
20 elements such as HSS. According to an operator policy, the subscription data can also be
retrieved from HSS.
[0101]
The UE can set a trigger event for being discovered and/or discovering and register its
policy profile in the ProSe server. The ProSe server can indicate a UE or discard it accordingly,
25 when there is a ProSe service request to the UE. The trigger events can be:
1) On location: when it goes somewhere to receive information, such as, coupons.
2) VIP member: when the given UE is nearby; and
3) Time etc.
[0102]
30 Upon receiving a ProSe Service Request from a UE, the ProSe server should verify the
following, before initiating the Discovery procedure.
1) Whether the requesting UE and the receiving UE are both ProSe enabled UEs, and they
have subscribed ProSe service,
2) Whether the requesting UE is allowed for discovering service,
20
3) Whether the receiving UEs are ProSe enabled UEs and allowed to be discovered, or
4) Whether the UEs are allowed to have the requested service and communication.
[0103]
After the verification, the ProSe server informs the requesting UE of the received
request and pending. The ProSe server should perform Discovery described above. Th5 e
ProSe server can request network support for those procedures. The ProSe server informs the
result of Discovery, containing a list of accepted UEs, allowed services, allowed communication
means, and any other necessary parameters.
[0104]
10 The requesting UE can automatically be the group manager if there is none and start to
perform authentication, authorization, and security association establishment in the group.
There are two cases:
Case 1C: The requesting UE wants to communicate with some UEs but does not know if they are
nearby and/or available,
15 Case 2C: The requesting UE using some application which shows that there are some UEs
nearby selects some UEs to have ProSe with.
[0105]
Here, details of the procedure in each case will be described as follows. Note that the
UEs can be subscribed to the same ProSe server or different ones.
20 [0106]
[[Case 1C]]: A UE does not have knowledge whether the receiving UEs are in proximity.
Fig. 6 is a flow chart showing a method of performing the group management of a Case
1C of an exemplary embodiment. As shown in Fig. 6, the system includes the UEa 21 serving
as a requesting UE, the UEb 22 serving as a receiving UE, a ProSe server 24, and an HSS 25.
25 The method includes the following nine steps SP1 to SP9.
[0107]
SP1: The ProSe server 24 stores subscription data of UEs.
SP2: The requesting UE 21 sends the ProSe Service Request to the ProSe server 24, containing a
requesting UE ID, a list of receiving UE IDs, a request service type, a request communication
30 type, an optionally group ID if the group has been formed before or the requesting UE wishes to
name the group ID, and an optionally range.
SP3: The ProSe server 24 can interact with the HSS 25 for authentication information of UE if
needed.
SP4: The ProSe server 24 performs verification on the requesting and receiving UEs 21 and 22.
21
SP5: The ProSe server 24 sends a ProSe Service ACK to the requesting UE 21, containing a
status of pending.
SP6: The ProSe server 24 performs Discovery procedure.
SP7: After the Discovery procedure, the ProSe server 24 sends the ProSe Service Result to the
requesting UE 21, with the group ID, the accepted UEs, the allowed service type, the allowe5 d
communication type, and the security parameters (optional).
SP8: The ProSe server 24 can also send the same ProSe Service Result to the receiving UEs 22.
SP9: Once the requesting and receiving UEs 21 and 22 know the allowed group members, the
group security establishment can be started.
10 [0108]
[[Case 2C]]: A UE recognizes that some other UEs are nearby.
In this case 2C, assuming that a subscriber runs an application that shows which UEs
are in proximity. The subscriber can choose with which UEs it wants to have the ProSe service.
Thus, the Discovery procedure is not needed. The ProSe server 24 will verify whether the
15 requesting UE 21 can have the ProSe service with the receiving UEs 22 in the same way
described in Case 1C.
[0109]
To summarize the above description, the method of performing a secure group
management of an exemplary embodiment includes the following features:
20 (1) The ProSe server is configured with subscription data of UEs, containing UE capability of
ProSe service, information of UEs which can have the ProSe service, and the policy set by the
UEs;
(2) The ProSe server performs authorization on the requesting UE, to verify: whether it can have
requested the ProSe service with the communication type, and whether the requesting UE can
25 have the ProSe service with the given receiving UEs;
(3) The ProSe server performs authorization on the receiving UEs, to verify whether they can
have the ProSe service with the requesting UE;
(4) A UE can set the event trigger for discovering and being discovered with network
authorization;
30 (5) The ProSe server sends a ProSe Service Ack to the requesting UE with a status of pending;
and
(6) The ProSe server sends the ProSe Service Result to the requesting UE and also the receiving
UE, with a group ID, accepted UEs, an allowed service type and a communication type, and
security parameters (option).
22
[0110]
According to the secure system of an exemplary embodiment of the invention, a
network controls whether the requesting and receiving UEs can have ProSe service with each
other. The requesting UE can select receiving UEs with which the requesting UE wants to have
the ProSe service, and requests a network to perform authorization. Furthermore, 5 , the
requesting and receiving UEs can set an event trigger for discovering and being discovered, such
that it can have a customized setting.
[0111]
This software can be stored in various types of non-transitory computer readable media
10 and thereby supplied to computers. The non-transitory computer readable media includes
various types of tangible storage media. Examples of the non-transitory computer readable
media include a magnetic recording medium (such as a flexible disk, a magnetic tape, and a hard
disk drive), a magneto-optic recording medium (such as a magneto-optic disk), a CD-ROM
(Read Only Memory), a CD-R, and a CD-R/W, and a semiconductor memory (such as a mask
15 ROM, a PROM (Programmable ROM), an EPROM (Erasable PROM), a flash ROM, and a
RAM (Random Access Memory)). Further, the program can be supplied to computers by using
various types of transitory computer readable media. Examples of the transitory computer
readable media include an electrical signal, an optical signal, and an electromagnetic wave.
The transitory computer readable media can be used to supply programs to computer through a
20 wire communication path such as an electrical wire and an optical fiber, or wireless
communication path.
[0112]
This application is based upon and claims the benefit of priority from Japanese Patent
Application No. 2013137291, filed on June 28, 2013, the disclosure of which is incorporated
25 herein in its entirety by reference.
[Reference Signs List]
[0113]
1 secure system
30 10 system
11 UE
12 UE
13 E-UTERN
14 EPC
23
15 ProSe Function
16 ProSe APP Server
17 ProSe APP
18 ProSe APP
19 e5 NB
20 eNB
21 UEa
22 UEb
24 ProSe Server
10 25 HSS
31 UEa
32 UEb
33 UEc
33n UEn
15 100 UE
100a system
100b system
200 network
L01 requesting UE
20 L02 operator network
L03 receiving UE
L1 secure group management
L2 secure discovery
L3 initial authorization
25 L4 authentication
L5 authorization
L6 security association establishment
L7 secure communication
L8 termination

WE CLAIM:
[Claim 1]
A method of forming a secure group in Proximity based Service (ProSe) communication
by a requesting device which requests a communication and a receiving device which receives 5 s a
communication request from the requesting device, wherein the requesting and receiving devices
have subscribed ProSe service, the method comprising:
requesting a service request to a ProSe server from the requesting device, the service
request indicating a request to communicate with the receiving device from the requesting
10 device;
performing verification on the requesting and receiving devices by the ProSe server;
sending a ProSe Service result to the requesting and receiving devices to inform to be
allowed a group member; and
starting a group security establishment of the group including the requesting and
15 receiving devices.
[Claim 2]
The method of forming a secure group in ProSe communication according to claim 1,
wherein
20 the service request contains a requesting device ID, a list of receiving device, a request
service type, and a request communication type.
[Claim 3]
The method of forming a secure group in ProSe communication according to claim 1 or
25 2, further comprising:
performing a discovery procedure by the ProSe server to obtain location information of
the receiving device, in case where the requesting device does not know if the receiving device is
within a predetermined area from the requesting device and/or available for the communication.
30 [Claim 4]
The method of forming a secure group in ProSe communication according to claim 3,
wherein
the performing discovery is verifying whether the requesting and receiving devices are
both ProSe enabled devise, whether the requesting device is allowed for discovering service,
25
whether the receiving device is ProSe enabled device and allowed to be discovered, and whether
the requesting and receiving devices are allowed to have a request service and a request
communication by the service request.
[Claim 5 laim 5]
The method of forming a secure group in ProSe communication according to any of
claims 1 to 4, wherein subscribed data of the requesting and receiving devices is stored in the
ProSe server and/or other server, the other server being able to be accessed from the ProSe
server.
10
[Claim 6]
The method of forming a secure group in ProSe communication according to claim 5,
wherein the subscription data indicates whether the requesting device is ProSe enabled,
wherein the ProSe enabled indicates a ProSe capability of the requesting and receiving
15 devices, the capability including whether device can discover other device and/or whether device
can be discovered by other device.
[Claim 7]
The method of forming a secure group in ProSe communication according to claim 3 or
20 4, further comprising:
setting a trigger event for being discovered and/or discovering and register a policy
profile of the trigger event in the ProSe server,
wherein the trigger event is any one or more of cases where the requesting and/or
receiving devices move to a given location or area, a specific device approaches or is approached
25 within a predetermined distance from the requesting and/or receiving devices, and a set time
comes.
[Claim 8]
A secure system including a plurality of User Equipments (UEs) and a Proximity based
30 Service (ProSe) server, comprising:
a requesting device which requests a communication; and
a receiving device which receives a communication request from the requesting device,
wherein the requesting device and the receiving device have subscribed ProSe service;
the requesting device requests a service request to the ProSe server, the service request
26
indicating a request to communicate with the receiving device from the requesting device;
wherein
the ProSe server performs verification on the requesting and receiving devices;
the ProSe server sends a ProSe Service result to the requesting and receiving devices to
inform to be allowed a group member; 5 r; and
the requesting and receiving devices start a group security establishment of the group
including the requesting and receiving