Description
Title of Invention: SECURE DISCOVERY FOR PROXIMITY
BASED SERVICE COMMUNICATION
Technical Field
[0001] This invention is related to a secure system and a method of performing a secure
discovery, more specifically, to a secure system that provides a method of performing
secure discovery to form a group and secure communication between members of a
specific group.
Background Art
[0002] 3GPP (3rd Generation Partnership Project) has started to study Proximity based
Services (ProSe) for both commercial and public safety uses. 3GPP SAl (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
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] ProSe communication can provide services to the UEs in proximity via an eNB
(Evolved Node B) or without the eNB. The SAl 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.
Citation List
Non Patent Literature
[0005] NPL 1: 3GPP TR 22.803 Feasibility study for Proximity Services (ProSe), (Release
12)
Summary of Invention
Technical Problem
[0006] However, despite the security issues involving secure Discovery (Detection) of UEs
in proximity as well as privacy issues, 3GPP SA3 offers no security solution.
Solution to Problem
[0007] The present invention has been made to present an overall security solution for the
above-mentioned security issues.
[0008] In one embodiment, there is provided a method of performing a secure discovery of
devices in Proximity based Service (ProSe) communication by a requesting device
which sends a request of a communication and a receiving device which receives the
request from the requesting device, the method including requesting a ProSe service
request to a ProSe server from the requesting device, performing verification on the requesting
and receiving devices by the ProSe server, performing a discovery procedure
by the ProSe server to obtain location information of the receiving device, and sending
a ProSe service result to the requesting device. The performing discovery procedure
includes sending the ProSe service request to a receiving device, performing source
verification to see if the request is from an authorized ProSe server by the receiving
device, checking discovery criteria to see whether the discovery criteria should have
the requested service by the receiving device, and sending a ProSe service accept
message to the ProSe server, if the performing source verification and the checking
discovery criteria are successful.
[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 sends a request of a communication, and a receiving device
which receives the request from the requesting device. The requesting device sends a
ProSe service request to the ProSe server. The ProSe server performs verification on
the requesting and receiving devices. The ProSe server performs a discovery procedure
to obtain location information of the receiving device. The ProSe server sends a ProSe
service result to the requesting device. In the discovery procedure, The ProSe server
sends the ProSe service request to a receiving device, the receiving device performs
source verification to see if the request is from an authorized ProSe server, the
receiving device checks discovery criteria to see whether the discovery criteria should
have the requested service, and the receiving device sends a ProSe service accept
message to the ProSe server, if the performing source verification and the checking
discovery criteria are successful.
Advantageous Effects of Invention
[0010] A secure system and a method of making a secure communication can present an
overall security solution for security issues.
Brief Description of Drawings
[001 I] 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. lA]Fig. 1A is a schematic view showing the ProSe Communication scenario in
NPL 1;
[fig. lB]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 invention;
[fig.3]Fig. 3 is a schematic view showing a secure system of an exemplary embodiment
of the present invention;
[fig.4]Fig. 4 is a sequence diagram explaining a method of making a secure communication
of an exemplary embodiment of the invention;
[fig.SA]Fig. 5A is a schematic view showing a One-to-one session;
[fig.SB]Fig. 5B is a schematic view showing a One-to-many session; and
[fig.SC]Fig. 5C is a schematic view showing a Many-to-many session.
[fig.6]Fig. 6 is a flow chart showing discovering the receiving UE by the ProSe server
of an exemplary embodiment of the invention.
Description of Embodiments
[OO 121 For purposes of the description hereinafter, the terms "upper", "lower", "right", "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 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] 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 be explained.
[OO 151 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 network node.
[OO 161 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 UE.
[0017] Prose-enabled Public Safety UE:
A Prose-enabled UE that also supports ProSe procedures and capabilities specific to
Public Safety.
[OO 181 Prose-enabled non-public safety UE:
A UE that supports ProSe procedures but not capabilities specific to public safety.
[OO 191 ProSe Direct Discovery:
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:
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 served by the same eNB 19 and network coverage is available, a system
lOOa 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.
IA. For charging, modifications should be 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 in Fig. IA.
[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 lOOb can decide to
perform ProSe Communication using control information exchanged between the UEs
1 1, 12, eNB 19 and the EPC 14 (e.g., session management, authorization, security) as
shown by the solid arrows in Fig. IB. In this configuration, the eNBs 1 1 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. IB. For charging, signaling modifications should be 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. IB.
[0023] If network coverage is available for a subset of the UEs, one or more Public Safety
UEs 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 preconfigured
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] 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] The UE 11 and the UE 12 can communicate through a PC5, the UE 11 and the EUTERN
13 communicate through LTE-Uul, 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
SGl and a PCl, respectively, and 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 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:
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 ProSeenabled
Public Safety UEs, regardless of whether the UEs are served by E-UTRAN or
not.
[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".
[0030] PCl:
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.
[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 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.
PC3:
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.
PC4:
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.
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).
PC6:
This reference point may be used for functions such as ProSe Discovery between
users which are subscribed to different PLMNs.
SGi:
In addition to the relevant functions defined in TS 29.061 [lo] via SGi, it may be
used for application data and application level control information exchange.
Fig. 3 is a schematic view showing a secure system of an exemplary embodiment of
the 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 LOl, 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 Ll, a secure
discovery L2, an initial authorization L3, an authentication L4, an authorization L5, a
security association establishment L6, a secure communication L7, and a termination
L8, which are performed between UEs (the requesting UE LOl, the receiving UE L03)
with or without interacting with the operator network L02.
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 multiple-casting and one-to-one communications as shown in Figs. 1 A, IB,
and 2.
From setting up of a group till communication termination, security is needed in each
step as described below. Note that steps Ll - L 4 can be in a different order depending
on the service or application.
Ll : 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.
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 and a device should be able to authenticate the message.
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 start.
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.
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.
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.
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.
L8: Termination
The secure termination can provide security when UE(s) suspend or terminate the
communication, or when the entire group communication is terminated.
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.
[0049] [I] Group setting and management (Ll)
A group can be
(I) 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
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 changed. To form a group, the operator network LO2 can check the requesting UE
LO1 which requests the UE LO3 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 LO1 and the receiving UE L03) of the request and formation.
[005 11 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 I). 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 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
"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.
[0053] [2] Discovery - Secure detection of UEs in proximity (L2)
Discovery and group creation in [I] can happen at the same time or be independent
procedure.
There can be following three means that a UE (the requesting UE LOl) can discover
other UEs (the receiving UEs L03) in proximity: (I) 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- 11 Broadcast based solution
There are six ways (sl - s6) in Broadcast based solution:
[0055] (s 1) Token
The broadcast message can contain a token that only the given UEs can have. The
token should be used only once to prevent the receiving side from reusing it. In order
[0057]
[OOS 81
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.
(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 here.
(s3) Message ID
The broadcast message can have an ID that can be verified during the authentication
and is used initially only for authorization.
(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.
( ~ 5K)e y
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.
(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.
[2-21 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 LOI), and the location
information can be protected by the existing network security mechanism.
[2-31 Device service level information based solution
The requesting UE LO1 can use location information provided by a social network or
other services. Security can be ensured in an application layer.
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 IA:
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 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.
If the ProSe server performs the authorization, the UEs 100 enable the ProSe and/or
UEs 100 to be allowed to get given service/cornrnunication means.
If the discovery is done based on the proximity of UEs 100, the UE 100 sends
location 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.
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 happens.
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 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 communication L7), as shown in
Fig. 4. The steps 5 to 7 can happen together, and might be related to broadcast security
[3] Initial Authorization (L3)
The initial authorization varies according to the above discovery solution.
[3- 11 Broadcast based:
Whether the requesting UE LO1 is allowed to communicate with the receiving UE
LO3 can be checked by a network or by the receiving UE LO3 having a proof provided
by the network.
[3-21 Network based:
The requesting UE LO1 and the receiving UE LO3 can perform a mutual authentication
over the direct wireless interface.
[3-31 Device service level information based:
The receiving UE LO3 checks a list maintained by the user or in a UE among the
members of the group of devices for ProSe service purpose.
[4] Authentication (L4)
Once the requesting UE LO1 is identified as belonging to the same group, then authentication
takes place. Authentication can be carried out locally or by interacting
with the network.
[4- 11 Authentication of the requesting UE LOl:
This can be performed by successful identification of the requesting UE LO1 by a
network or a UE with a proof from a network.
[4-21 Authentication of the receiving UE L03:
This can be performed by
[4-2-i] using a key shared between the requesting UE LO1 and the receiving UE LO3
[4-2-ii] using current network security keys or new keys
[4-2-iii] a network which informs the requesting UE LO1 of the incoming authentication
request from the receiving UE L03.
[SIAuthorization - service access control (L5)
There should be different levels for access control to services that the requesting UE
LO1 and the receiving UE LO3 (hereinafter also referred to as "UE") can use within the
group.
[5-l]UE is allowed to receive and/or send a broadcasting message.
[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-41 UE authorization according to subscription information and the policy UE set
for ProSe service.
A network can set up and provide the policy to the group members including the requesting
UE LO1 and the receiving UE LO3 according to UE capabilities and user subscriptions.
The network 200 performs authorization for the UEs 100 want to join the group. The
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 (I) 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 receiving UE requests the Network to
validate this authorization value and receiving result.
[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
indicator KSI-p related to it. Kp can be sent from ProSe Server to use.
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 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 LO1 and the receiving UE LO3 can start sessions to communicate with
each other. When the requesting UE LO1 and the receiving UE LO3 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.
[008 11 The key can be managed by the network and sent over the secure communication
channel with the network. Alternatively, the key can be managed by the requesting UE
LO1 and sent to other devices including the receiving UE LO3 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] 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 LOl, and a UEb 22,
a UEb 32, a UEc 33 and a UEn-33n indicate the receiving UE L03.
[0083] When the session is started, firstly session keys are generated. In this exemplary embodiment,
the requesting UE LO1 (UEa 21, the UEa 3 1) and the receiving UE LO3
(UEb 22, the UEb 32, the UEc 33, the UEn-33n) use two kinds of keys including
session keys.
Case IB:
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 session.
In each case, either the ProSe server or the requesting UE LO1 sends keys. For
example, the ProSe server sends the key Kp to the requesting UE LO1 and the
receiving UE(s) L03, and the requesting UE LO1 sends a session key to the receiving
UE(s) LO3 every session. Alternatively, the ProSe server sends both of the key Kp and
the session key to the requesting UE LO and the receiving UE(s) L03, or the requesting
UE LO1 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 a key times out, or when the ProSe server has made a decision, for example, the key
Kp andor the session key should be changed.
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 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.
Note that the key set identifier (KSI) is a number which is associated with the cipher
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 procedure. This is used to allow reuse
of the cipher key CK and integrity key IK during subsequent connections (session).
[7] Secure Communication (L7)
Secure communication can provide message transmission availability between group
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.
The communication within the group should have integrity and/or confidentiality
protection. All the communications can be protected by the session keys described
above, after the security association is established.
The security policy can be a negotiation and an agreement within the group with or
without the support of the operator network L02. All the group members should follow
the security policy.
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 changed location, but stayed in proximity to each other, then there is still
no security issue.
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 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.
Note that the ProSe Server should get UE location information from GMLC
(Gateway Mobile Location Center) periodically, to compare and compute the location
differences of all UEs.
[8] Termination (L8)
When the communication is to be suspended, devices should remove the session key
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.
[0096] Smooth handover from an infrastructure to a direct mode will require creation of a
key between communicating parties (the requesting UE LO1 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 each 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 ProSe APP Server.
[0097] To summarize the above description, the method of making a secure communication
of an exemplary embodiment includes the following features:
(I) The operator network LO2 determines whether the requesting UE LO1 can communicate
with the receiving UE LO3 requested by the requesting UE LOl.
(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.
(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 LO1 and the receiving UEs that
agreed to be in the group LO3 can be carried out by the network and also both UEs can
be informed with the result.
(7) Mutual authentication between the requesting UE LO1 and the receiving UEs LO3
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 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] According to the secure system of an exemplary embodiment, the operator network
LO2 can determine the receiving UE(s) LO3 with which the requesting UE LO1 can
communicate, and can ensure secure discovery by either providing security parameters
to the requesting UE LO1 or receiving UE L03, and providing location information of
the receiving UE LO3 to the requesting UE LOl. Furthermore, the operator network
LO2 can perform authentication and authorization for the requesting UE LO1 and
receiving UE L03, and can support security association between UEs to secure ProSe
communication.
[0099] [9] A detailed method of performing secure Discovery (L2)
Next, a detailed method of performing secure Discovery L2 will be explained. The
Discovery can be initiated when the serving node of the requesting UE receives a
ProSe service request from the requesting UE, and the subscriber information is
verified as described above.
[0100] As described earlier, there are three means [2- 11 to [2-31 to discover the receiving
UEs. For example, discovering the receiving UEs is performed by obtaining the
receiving UEs location information.
[0101] [Solution I] Broadcast based solution: this also can be multi-cast or unicast
depending on how many UEs the requesting UE wants to have ProSe service with.
This solution can be used when the ProSe server does not know the location information
of receiving UEs.
[Solution 21 Network based solution; and
[Solution 31 Device service level information based solution: in solutions 2 and 3, the
network knows whether the receiving UEs are in proximity, and it can respond to the
requesting UEs with available receiving UEs.
Further detailed description of the solutions is given below.
[0102] [[Solution 111 Broadcast based solution
The network element which performs "Discovery" can interact with HSS to obtain
the requesting UE's current location and serving node information. The network
element can send a broadcast message under the same coverage with the same serving
node (MME).
The message should contain the requesting UE ID, service type, and communication
type.
[0103] Depending on the service type and communication type indicated in the ProSe
Service Request, the ProSe server should determine how to notify the receiving UEs in
proximity. The ProSe server can send a ProSe service request notification to the
receiving UEs by one of the three means: 1) broadcasting, 2) multi-casting, and 3)
unicast.
[0104] The receiving UE will perform the source verification to check whether it is from a
trusted network element, and also to check if the service and communication type are
acceptable. The receiving UE will respond to a ProSe server accept or reject response
with a proper cause. The ProSe server will verify the response source and the source
location. After successful verification, the ProSe server will inform the requesting UE
of the receiving UEs that have accepted to have the ProSe service. A response from the
receiving UE which is longer than an expected time which is set by the requesting UE
or ProSe server should be discarded.
[0105] Fig. 6 is a flow chart showing discovering the receiving UE by the ProSe server of an
exemplary embodiment of the invention.
(SPll) Assuming that the ProSe server 24 has verified the subscription data and
Discovery criteria of the requesting and the receiving UEs 21 and 22.
(SP12) The ProSe server 24 determines the message type, if it needs to send a
message to receiving UEs.
(SP13) The ProSe server 24 sends the ProSe Service Request to the receiving UEs
22, with a requesting UE ID, a receiving UE ID, a service ID, and an message ID.
(SP14) The Receiving UE 22 will perform source verification to see if the request is
from an authorized ProSe server 24.
(SP15) The Receiving UE 22 also checks its discovery criteria, to see whether it
should have the requested service.
(SP16) The Receiving UE 22 sends a ProSe Service Accept message to the ProSe
server 24, the ProSe Service Accept message including the requesting UE ID,
receiving UE ID, service ID, and message ID, if the performing the source verification
in SP14 and the checking the discovery criteria in SP15 are successful.
(SP17) The Receiving UE 22 sends a ProSe Service Reject message to the ProSe
server 24, the ProSe Service Reject message including the requesting UE ID, receiving
UE ID, service ID, message ID, and a proper cause of rejection, if the performing
source verification and the checking discovery criteria are not successful.
(SP18) The ProSe server 24 performs verification on the source of ProSe Service
Accept or ProSe Service Reject message, the message integrity, and the message ID.
(SP19) The ProSe server 24 sends ProSe Service Result to the requesting UE 21 as
described in [3].
[0106] In the following, a method of protecting and verifying the broadcast message is
presented.
(s 1) Token
The broadcast message can contain a token that only the given UEs can have. The
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 information notification kind of service, since the token
can be reused by the receiving side.
(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 here.
(s3) Message ID
The broadcast message can have an ID that can be verified during the authentication
and is used initially only for authorization.
(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.
( ~ 5K)e y
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.
(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.
[[Solution 211 Network based solution
The network can have location information of a given UE. There are three ways the
network can obtain the information.
(I) Location information can be sent periodically by the UE to the network.
(2) The network can know the location of the UE based on already existing solutions
in the network, but in this case, the issue is with idle devices that do not continuously
update their locations.
(3) The network can ping the UE for location information.
According to the policy, the UE set for discovery and/or discoverable network sends
location information to the UEs or to the group members if the group is created. The
UEs can approach each other for communication.
[[Solution 311 Device service level based solution
Several social network services have location information; this could be used by a
UE to know the location information of those in the group. This also means that the
UE should know who belongs to which group; otherwise the group setting can be automatically
done in the device by SNS information.
For example, the UE can gather information about connections of a subscriber in
FaceBook (R) and check FaceBook (R) information periodically to know location
updates. In this way, the UE knows of the group and location of members. The UE
could combine information from different services like Twitter (R), FaceBook (R), etc.
[0116] To summarize the above description, the method of performing a secure Discovery
of an exemplary embodiment includes the following features:
(I) The ProSe server can determine how to notify the receiving UEs of the ProSe
Service Request from the requesting UE;
(2) There are three ways the ProSe server can send the above-mentioned notification:
broadcasting, multi-casting, or unicast;
(3) The broadcast message can be protected in one of the 6 ways of solutions (s 1) to
(~6);
(4) Upon receiving a broadcast message, the receiving UE verifies the source
integrity;
(5) Upon receiving a broadcast message, the receiving UE verifies whether the
requested service and the communication type are acceptable;
(6) The receiving UE sends to the ProSe server an accept or reject response with: a
proper cause, a receiving UE ID, a requesting UE ID, and a service ID;
(7) The ProSe server verifies the response UE source and its location;
(8) The ProSe server informs the requesting UE of the receiving UEs that have
accepted to have the ProSe service;
(9) A response from the receiving UE which is longer than an expected time which is
set by the requesting UE or the ProSe server is discarded;
(10) The ProSe server can know the receiving UE location information from periodical
location information sent from UEs;
(1 1) The ProSe server can know the receiving UE location information from existing
solutions;
(12) The ProSe server can know the receiving UE location information by pinging
the receiving UEs; and
(13) The ProSe server can know the receiving UE location information from the
device service based solution, such as social network services.
[0117] According to the secure system of an exemplary embodiment the invention, the
ProSe server in 3GPP network can discover the UEs with which a requesting UE wants
to have the ProSe service, by either sending broadcasting message or obtaining their
location information. The broadcasting message from the ProSe server and the
response from the receiving UE can be integrity protected such that the source integrity
is verified. The ProSe server can verify the receiving UE location, which can be optionally
supported by other network elements or services.
[0118] This software can be stored in various types of non-transitory computer readable
media 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 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 wire
communication path such as an electrical wire and an optical fiber, or wireless communication
path.
[0119] This application is based upon and claims the benefit of priority from Japanese Patent
Application No. 2013 137292, filed on June 28,2013, the disclosure of which is incorporated
herein in its entirety by reference.
Reference Signs List
[0120] lsecuresystem
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
26 operator network
3 1 UEa
32 UEb
33 UEc
33n UEn
100 UE
lOOa system
lOOb system
200 network
LO1 requesting UE
LO2 operator network
LO3 receiving UE
Ll secure group management
L2 secure discovery
L3 initial authorization
L4 authentication
L5 authorization
L6 security association establishment
L7 secure communication
L8 termination

Claims
[Claim I]
[Claim 21
[Claim 31
[Claim 41
A method of performing a secure discovery of devices in Proximity
based Service (ProSe) communication by a requesting device which
sends a request of a communication and a receiving device which
receives the request from the requesting device, the method
comprising:
requesting a ProSe service request to a ProSe server from the requesting
device;
performing verification on the requesting and receiving devices by the
ProSe server;
performing a discovery procedure by the ProSe server to obtain
location information of the receiving device; and
sending a ProSe service result to the requesting device,
wherein the performing discovery procedure includes
sending the ProSe service request to a receiving device;
performing source verification to see if the request is from an authorized
ProSe server by the receiving device;
checking discovery criteria to see whether the discovery criteria should
have the requested service by the receiving device; and
sending a ProSe service accept message to the ProSe server, if the
performing source verification and the checking discovery criteria are
successful.
The method of performing a secure discovery of devices in ProSe communication
according to claim 1,
wherein the ProSe service request includes a requesting device ID, a
receiving device ID, a service type, and a communication type.
The method of performing a secure discovery of devices in ProSe communication
according to claim 1 or 2,
wherein the ProSe service accept message includes the requesting
device ID, the receiving device ID, the service type, and the communication
type.
The method of performing a secure discovery of devices in ProSe communication
according to claim 2 or 3,
wherein the performing discovery procedure further includes
sending a ProSe service reject message to the ProSe server, if the
performing source verification and the checking discovery criteria are
not successful, the ProSe service reject message includes the requesting
[Claim 51
[Claim 61
device ID, the receiving device ID, and a proper cause of rejection.
The method of performing a secure discovery of devices in ProSe communication
according to any one of claims 1 to 4,
wherein communication between the receiving device and the ProSe
server and between the ProSe server and the receiving device is
performed by a broadcast message,
wherein the broadcast message is protected andor verified by one or
more of a token, a first key, a verified ID, a random value, a second
key, and a time-stamp,
wherein the broadcast message contains a token that only given devices
have, is signed by the first key that is verified either by the receiving
device or by the network for the receiving device, has an verified ID
verified during authentication, contains a random value that is only
generated by the network and the requesting and receiving devices, is
sent in pieces with encryptedintegrity protected parts for each device
in the group with the second key, or is signed with time-stamp.
A secure system including a plurality of User Equipments (UEs), and a
Proximity based Service (ProSe) server comprising:
a requesting device which sends a request of a communication; and
a receiving device which receives the request from the requesting
device,
wherein
the requesting device sends a ProSe service request to the ProSe server;
the ProSe server performs verification on the requesting and receiving
devices;
the ProSe server perform a discovery procedure to obtain location information
of the receiving device; and
the ProSe server sends a ProSe service result to the requesting device;
wherein, in the discovery procedure,
the ProSe server sends the ProSe service request to a receiving device;
the receiving device performs source verification to see if the request is
from an authorized ProSe server;
the receiving device checks discovery criteria to see whether the
discovery criteria should have the requested service; and
the receiving device sends a ProSe service accept message to the ProSe
server, if the performing source verification and the checking discovery
criteria are successful.