WO2016162759A2

WO2016162759A2 - Secure service request using an application granted key

Info

Publication number: WO2016162759A2
Application number: PCT/IB2016/000752
Authority: WO
Inventors: Simon MIZIKOVSKY; Nagendra S BYKAMPADI; Suresh P Nair
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2015-04-10
Filing date: 2016-04-11
Publication date: 2016-10-13
Anticipated expiration: 2017-10-10
Also published as: WO2016162759A3

Abstract

In one embodiment a method includes receiving from a first user equipment device a first proximity request including an identity of a second user equipment device. A map request including the identity is directed to a Pro Se Application Server. A map response including a verification key is received from the Application Server in response to the map request. A second proximity request that includes the verification key is directed to a Pro Se function associated with the second user equipment device.

Description

SECURE SERVICE REQUEST USING AN APPLICATION GRANTED KEY

TECHNICAL FIELD

The present invention relates generally to the field of telecommunications, and, more particularly, but not exclusively, to methods and apparatus useful for implementing proximity-based services (ProSe).

BACKGROUND

This section introduces aspects that may be helpful to facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art. Any techniques or schemes described herein as existing or possible are presented as background for the present invention, but no admission is made thereby that these techniques and schemes were heretofore commercialized, or known to others besides the inventors.

To support proximity-based services (ProSe) in an LTE network, user devices (UEs) need to discover their peer devices when the peer devices are in close proximity. According to the ProSe functional architecture defined by the relevant 3GPP technical standards, e.g. TS 23.303 and TS 33.303, a UE estimates the proximity of a peer using the peer device's location, with assistance of the associated ProSe functions in the network, as well as cellular location-based services. More specifically, a ProSe-capable User Device A (UE_A) requests of an associated ProSe Function (ProSe_Fn_A) residing on a public land mobile network (PLMN) node to be notified when a peer User Device B (UE_B) comes into proximity of UE_A. This request is indicated to be valid within a certain time window, outside of which the UE_A is assumed to be no longer interested in the UE_B's proximity. The ProSe_Fn_A function receives discovery authorization from a ProSe Application Server, along with discovery- specific parameters. The ProSe_Fn_A function then sends a request for the location of the UE_B to the ProSe Function associated with UE_B, e.g. ProSe_Fn_B. The ProSe Function ProSe_Fn_B needs to verify whether the requested operation received from the ProSe_Fn_A is authorized by the ProSe Application Server, and that the request is indeed issued by the legitimate ProSe_Fn_A. If the request is genuine and authorized, then ProSe Function ProSe_Fn_B contacts a Location server (SLP) to determine the location of UE_B.

SUMMARY

The inventors disclose various apparatus and methods that may be beneficial applied to providing proximity services (ProSe) in a mobile telephonic network environment. While such embodiments may be expected to provide improvements in performance and/or reduction of cost of such apparatus and methods, no particular result is a requirement of the present invention unless explicitly recited in a particular claim.

One embodiment provides a method, e.g. of providing ProSe services, that includes receiving from a first user equipment device a first proximity request including an identity of a second user equipment device. A map request including the identity is directed to a ProSe Application Server. A map response including a verification key is received from the Application Server in response to the map request. A second proximity request that includes the verification key is directed to a ProSe function associated with the second user equipment device.

In some embodiments the map response includes a verification key identity. In some embodiments the map response includes a verification key lifetime. In some embodiments the map response includes a parameter indicating operations the ProSe function is authorized to perform. In some embodiments the second proximity request includes a verification key lifetime. In some embodiments the second proximity request includes an identity of the verification key.

Another embodiment provides another method, e.g. of providing ProSe services, that includes receiving a proximity request for a target user equipment (UE) from a requesting ProSe Function. The proximity request includes a first instance of a verification key, a signature derived from the verification key, and a lifetime of the verification key. The method further includes directing to a ProSe Application server, in response to the proximity request, a verification request to verify the verification key. Additional verification requests are disabled within a duration of the lifetime.

In some embodiments the verification request includes an identity of the verification key. Some embodiments further include receiving from the ProSe application server, in response to the verification request, a second instance of the verification key, and verifying the signature using the second instance of the verification key. Some embodiments further include directing to the ProSe function an acknowledgement of the proximity request on the condition that the signature is successfully verified, the acknowledgement including a location of the target UE signed with the verification key.

Another embodiment provides an apparatus, e.g. a public land mobile network (PLMN) Application Server, that includes a processor and a non-transitory storage medium. The storage medium includes instructions that when executed by the processor configure the processor to receive a map request from a first ProSe function. The processor is further configured by the instructions to direct to the first ProSe function in response to the map request a map response including a verification key. Upon request from a second ProSe function (ProSe Function B), the processor directs the verification key to the second ProSe function.

In some embodiments the map response includes a verification key identity. In some embodiments the map response includes a verification key lifetime. In some embodiments the map response includes a parameter indicating operations the ProSe function is authorized to perform. In some embodiments the verification key lifetime is directed, in response to the request, to the second ProSe function with the verification key. In some embodiments the request from the second ProSe function includes an ID of the verification key.

Another embodiments provides a method, e.g., of manufacturing a public land mobile network application server. A non-transitory storage medium is provided that includes instructions stored thereon. A processor is configured to read the instructions, wherein the processor is configured by the instructions to implement any of the methods described above. BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:

FIG. 1 illustrates a conventional exchange between elements of a telecommunications system for implementing ProSe services;

FIG. 2 illustrates an embodiment of exchange between elements of a telecommunications system consistent with the disclosure for implementing ProSe services; and

FIG. 3 illustrates an apparatus, e.g. a PLMN Application Server, according to one embodiment.

DETAILED DESCRIPTION

Various embodiments are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident, however, that such embodiment(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more embodiments.

The request by the UE_A to the ProSe_Fn_A for proximity of UE_B includes an indication of a time window within which the request is valid. Outside of this window, the ProSe User A is assumed to be no longer interested in the proximity of User B. The grant by the ProSe Application Server proximity discovery within the specific time window is conventionally unsecure, creating a risk of a replay attack by a malicious entity, e.g. a violation of subscription rights of UE_A and UE_B. Accordingly a scheme is needed to protect the UE_A and UE_B misuse of the ProSe protocol by an impersonator. Embodiments described herein may provide functionality that ensures the protection of the messages exchanged between the ProSe Functions in the network for the purpose of proximity detection. FIG. 1 illustrates a conventional implementation of a method 100 of providing ProSe services, such as an "Application Server-signed Proximity Request". This method is described in, e.g., ETSI standard 3GPP TS 33.303, version 13.2.0, Release 13 ("TS 33.303"), incorporated herein by reference in its entirety. Four entities interact in the method 100, a UE_A 110, a ProSe Function A (sometimes abbreviated ProSe_Fn_A) 120, a ProSe Application Server 130 and a ProSe Function B (sometimes abbreviated ProSe_Fn_B) 140. Those skilled in the pertinent art will appreciate that a ProSe Function is a logical function that is used for network-related actions required for ProSe services. {See, e.g. ETSI standard 3GPP TS 23.303, version 13.2.0, Release 13 ("TS 23.303"), incorporated herein by reference in its entirety, e.g. at Section 4.4.1.1.) The ProSe Function is implemented within the physical computing infrastructure that makes up a public land mobile network (PLMN) associated with the UE_A and the UE_B. In the general case that the UE_A and the UE_B are served by different PLMNs, the ProSe_Fn_A and the ProSe_Fn_B may be different instances of the ProSe Function running on the different PLMNs. In the case which the UE_A and the UE_B are served by the same PLMN, the ProSe_Fn_A and the ProSe_Fn_B may be a same instance of the ProSe Function.

In the method 100, the UE_A 110 initiates a proximity request, and therefore is sometimes referred to in the following discussion as the "requesting UE". A UE_B (not shown) is the target of the proximity request, and therefore is sometimes referred to in the following discussion as the "target UE". The method 100 is based on the signing, by the ProSe Application server 130, of parameters sent with a proximity request by the requesting UE, e.g. the UE_A 110. The signing makes use of a Public-Private Key Pair previously provisioned in the ProSe Application Server 130.

The illustrated steps of the method 100 are set forth below in tabular form:

• Step 1: The UE_A 110 directs a Proximity Request to the ProSe Function A 120. The request includes several parameters, including ALUID_A and ALUID_B, where ALUID refers to an Application Layer User ID, with ALUID_A being the identifier associated with UE_A and the ALUID_B being the identifier associated with UE_B. • Step 2: The ProSe Function A 120 directs a Map Request to the ProSe Application Server 130. This request includes the ALUID_A and ALUID_B received by the ProSe Function A 120 from the UE_A 110.

• Step 3: The Application Server 130 directs a Map Response to the ProSe Function A 120. Optionally the Map Response includes a certificate CertKey_AS of the verification key of the Application Server 130.

• Step 4: The ProSe Function A 120 directs a Proximity Request to the ProSe Function B 140. This request includes the CertKey_AS previously provided by the Application Server 130. The ProSe Function A 120 expects to receive a location of a UE_B (not shown) associated with the ProSe Function B 140 upon completion of the authentication method 100.

• Step 5: In this optional step, the ProSe Function B 140 requests the verification key of the Application Server 130. This step need only be performed if the Application Server 130 does not provide the CertKey_AS to the ProSe Function A 120 in Step 3, as may be the case in some operations.

• Step 6: In this optional step, the Application Server 130 provides the Verification Key to the ProSe Function B 140. This step need only be performed if Step 5 is performed.

• Step 7: The ProSe Function B 140 verifies the signature (either the CerKey_AS or the Verification Key, as appropriate.

Upon the completion of Step 7, the ProSe Function B 140 can provide ProSe services to the UE_A 100 on behalf of the associated UE_B, e.g. the location of the UE_B. If no proximity is detected by the ProSe Function A 120 from the reported UE_B location, the message 4 is periodically repeated.

As previously described, the Proximity Request from the UE_A 110 in Step 1 includes a time Window of interest. The method 100 is susceptible to a replay attack by a ProSe Function impersonator if Step 4 is periodically repeated within the specified time window of interest. Those skilled in the pertinent art will appreciate that in a replay attack, a malicious impersonator may duplicate an authentic entity' s message to impersonate the authentic entity. In the context of the method 100, the signature of the Application Server 130 would be identical for the ALUID_A and ALUID_B sent in Step 2. Therefore, the request by the ProSe Function A 120 or an impersonator and destined to the ProSe Function B 140 would typically carry the same signature within the Window specified in Step 1 when the private key of the Application Server 130 is used to digitally sign the request. This allows for the attacker to replay the Proximity Request message (Step 1) to the target ProSe Function (ProSe Function B 140) without being recognized by the target ProSe Function. The attacker is thereby able to obtain the target' s location within the specified lifetime window.

FIG. 2 illustrates an embodiment, e.g. a method 200, that may overcome the replay attack vulnerability of the method 100. In general terms, various embodiments require each Proximity Request to be signed freshly by the source ProSe Function, e.g. ProSe Function A 120, using a randomly-created key provided by the Application Server 130. In various embodiments this key remains valid within a specified window of interest, and may be only associated with the currently authorized proximity discovery session. This key may be provided by the Application Server 130 to the ProSe Function associated with the requesting UE as part of the Map Request/Map Response exchange. The target ProSe Function may fetches this key from the App Server with the initial VerifKey Request/VerifKey Response exchange and uses it throughout the specified window to verify the received signature of every received request associated with this proximity discovery session.

In various embodiments the UE A doesn't sign the proximity request sent to its ProSe Function A, but trusts the Application Server to control the authorization of the proximity request sent on its behalf.

The authorization criteria can be based on detection mechanisms of very high volume of incoming proximity requests from a ProSe Function that doesn't match with the frequency usage of the ProSe Application by the users, or it can be based on a presence detection mechanism over the PCI interface.

In various embodiments the ProSe Function A directs an authorization request to the Application Server for each proximity request it expects to transmit over the PC2 interface. The Application Server creates a verification key Kv, specifically for this request session, and returns parameters which specify which operations are authorized (e.g. authorized to send only one request, authorized to send X requests until particular date, etc .), the newly created verification key Kv. This Verification key will be valid as long as the EPUID_A and EPUID_B are associated in the discovery procedure during the active window (specified by the UE). Once the window closes, the Verification key Kv for this discovery pair shall be purged by the Application Server and ProSe functions involved in the proximity discovery.

ProSe Function B is assured of the authenticity of the proximity request received from ProSe Function A by verifying the signature with a verification key obtained from the Application Server.

The token verification key is fetched over the PC2 interface between the ProSe Function B and the Application Server.

The method 200 is now described in detail with reference to one example embodiment consistent with the disclosure.

• Step 1 : This step is unchanged from Step 1 of the method 100.

• Step 2: This step is unchanged from Step 2 of the method 100, with the exception of the addition of the Window Range parameter which indicates to the Application Server 130 that outside of this window it should not deliver this key to the requesting ProSe Function. In this step, the ProSe Function A 120 may further modify the Window Range based on the location, mobility, entitlement, etc. of the UE_A 110. Thus while the Window Range in Step 1 may be viewed as a requested range, the Window Range in Step2 may be viewed as an allowed Range.

• Step 3: In this step the Application Server 130 returns, as part of the Map Response, the following data in addition to the data returned in the conventional method 100: the authorized operations (e.g. authorized to send only one request, authorized to send X requests until particular date, etc .), the verification key Kv (specifically created for this instance of the Proximity Request from the UE_A 110), Kv_Lifetime, and Kv_ID. A duration of validity of the verification key Kv is represented by 'Kv_Lifetime' which is constrained to be less than or equal to duration of the window requested by the UE_A 110.

Step 4: In this step the ProSe Function A 120 computes a signature SIGNED of the cryptographic hash of the concatenation of the ALUID_A, the ALUID_B, the authorized operations and the timestamp value. The ProSe Function A 120 then sends a Proximity Request to the ProSe Function B 140 with the following additional data: the computed signature, ALUID_A, ALUID_B, the timestamp, the authorized operations, the Kv_ID, the Kv_Lifetime, and Application ID. Every Proximity Request sent by the ProSe_Fn_A to the ProSe Function B 140 is different from prior requests, because a new timestamp is used to generate a fresh signature for every request.

Step 5: The ProSe Function B 140 sends a Verification Key Request (VerifKey REQUEST) to fetch from the Application Server 130 the verification key, which is identified by the Application ID, ALUID_A and ALUID_B, and the Kv_ID. This step is disabled for subsequent requests received from ProSe Function A 120 for the same set of Application ID, ALUID_A and ALUID_B, the Kv_ID, within the duration of the Kv_Lifetime.

Step 6: The Application Server 130 returns a second instance of the verification key Kv for the currently active ALUID_A and ALUID_B pair involved in discovery procedure. The Application Server 130 also provides a second instance of the Kv_Lifetime.

Step 7: In this step the ProSe Function B 140 verifies the signature received from the ProSe Function A 120 in Step 4 using the verification key Kv received from the Application Server 230 in Step 6. If the verification is successful then the ProSe Function B 140 requests location information of the UE_B (not shown). This protocol is beyond the scope of the present disclosure, but is described in TS 23.303, e.g. at Step 5 of Section 5.5.5. • Step 8: The ProSe Function B 140 acknowledges the proximity request via a message directed to the ProSe Function A 120. This message includes the location (if known) of the UE_B, and is signed using the verification key Kv.

• Step 9: The ProSe Function A 120 verifies the integrity of the received message using its copy of the verification key Kv. If the verification is successful then the procedure continues from step 8 in Section 5.5.5 of TS 23.303.

• Step 10: If the signature was not authenticated in Step 9, the method 200 branches to Step 4 wherein the ProSe Function A 120 attempts again to establish ProSe services with the UE_B on the condition that the UE_A continues to expect the UE_B to be in proximity to the UE_A. This expectation may be determine, e.g. by a configuration parameter or by user input. If the UE_B is no longer expected to be in proximity, the method 200 may terminate with a cancellation request in Step 11.

Turning to FIG. 3, an apparatus, e.g. the Application Server 130, is shown in schematic form. A processor 310 is configured to communication with a memory 320 and a network interface 330. The network interface 330 is configured to communicate via a network, e.g. the Internet, thereby providing communication between the Application Server 130 and the ProSe Function A 120, and between the Application Server 130 and the ProSe Function B 140. The memory 320 contains non-transitory storage, and includes instructions that when executed by the processor 310 configure the Application Server 130 to perform the steps of the method 200 assigned to it. The components of the

Application Server 130, e.g. the processor 310, the memory 320 and the network interface 330, are not limited to any particular type, and may optionally be conventional.

Unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word "about" or "approximately" preceded the value of the value or range.

It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of this invention may be made by those skilled in the art without departing from the scope of the invention as expressed in the following claims. The use of figure numbers and/or figure reference labels in the claims is intended to identify one or more possible embodiments of the claimed subject matter in order to facilitate the interpretation of the claims. Such use is not to be construed as necessarily limiting the scope of those claims to the embodiments shown in the corresponding figures.

Although the elements in the following method claims, if any, are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence.

Reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. The same applies to the term "implementation."

Also for purposes of this description, the terms "couple," "coupling," "coupled," "connect," "connecting," or "connected" refer to any manner known in the art or later developed in which energy is allowed to be transferred between two or more elements, and the interposition of one or more additional elements is contemplated, although not required. Conversely, the terms "directly coupled," "directly connected," etc., imply the absence of such additional elements.

The embodiments covered by the claims in this application are limited to embodiments that (1) are enabled by this specification and (2) correspond to statutory subject matter. Non-enabled embodiments and embodiments that correspond to nonstatutory subject matter are explicitly disclaimed even if they formally fall within the scope of the claims. The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those of ordinary skill in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.

The functions of the various elements shown in the figures, including any functional blocks labeled as "processors," may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, in conjunction with the appropriate computer hardware, the particular technique being selectable by the implementer as more specifically understood from the context.

It should be appreciated by those of ordinary skill in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Although multiple embodiments of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications and substitutions without departing from the invention as set forth and defined by the following claims.

Claims

CLAIMS:

1. A method, comprising:

receiving from a first user equipment device a first proximity request including an identity of a second user equipment device;

directing to a ProSe Application Server a map request including said identity;

receiving from said Application Server in response to said map request a map response including a verification key; and

directing to a ProSe function associated with the second user equipment device a second proximity request that includes said verification key.

2. The method of Claim 1, wherein said map response includes a verification key identity.

3. The method of Claim 1, wherein said map response includes a verification key lifetime.

4. The method of Claim 1, wherein said map response includes a parameter indicating operations the ProSe function is authorized to perform.

5. The method of Claim 1, wherein said second proximity request includes a verification key lifetime.

6. The method of Claim 1, wherein said second proximity request includes an identity of said verification key.

7. A method, comprising:

receiving from a requesting ProSe Function a proximity request for a target user equipment (UE), including a first instance of a verification key, a signature derived from the verification key, and a lifetime of said verification key; directing, in response to said proximity request, to a ProSe Application Server a verification request to verify said verification key; and

disabling additional verification requests within a duration of said lifetime.

8. The method of Claim 7, wherein said verification request includes an identity of said verification key.

9. The method of Claim 7, further comprising receiving from said ProSe application server, in response to said verification request, a second instance of said verification key, and verifying said signature using said second instance of said verification key.

10. The method of Claim 9, further comprising directing to said ProSe function an acknowledgement of said proximity request on the condition that said signature is successfully verified, said acknowledgement including a location of said target UE signed with said verification key.

11. An apparatus, comprising:

a processor; and

a non-transitory storage medium having instructions stored thereon that when executed by said processor configure the processor to:

receive a map request from a first ProSe function;

direct to said first ProSe function in response to said map request a map response including a verification key; and

upon request from a second ProSe function, direct said verification key to said second ProSe function.

12. The apparatus of Claim 11, wherein said map response includes a verification key identity.

13. The apparatus of Claim 11, wherein said map response includes a verification key lifetime.

14. The apparatus of Claim 11, wherein said map response includes a parameter indicating operations the ProSe function is authorized to perform.

15. The apparatus of Claim 11, wherein in response to said request, said verification key lifetime is directed to said second ProSe function with said verification key.

16. The apparatus of Claim 11, wherein the request from the second ProSe function includes an ID of the verification key.

17. A method of manufacturing a public land mobile network application server, comprising:

providing a non-transitory storage medium having instructions stored thereon; configuring a processor to read said instructions, wherein the processor is configured by said instructions to:

receive a map request from a first ProSe function;

18. The method of Claim 17, wherein said map response includes a verification key identity.

19. The method of Claim 17, wherein said map response includes a verification key lifetime.

20. The method of Claim 17, wherein said map response includes a parameter indicating operations the ProSe function is authorized to perform.

21. The method of Claim 17, wherein in response to said request, said verification key lifetime is directed to said second ProSe function with said verification key.

22. The method of Claim 17, wherein the request from the second ProSe function includes an ID of the verification key.