CN107251591B - Systems, methods, and devices for secure device-to-device discovery and communication - Google Patents

Abstract

A User Equipment (UE) configured to: sending a direct communication request to a peer UE, wherein the direct communication request includes a signature authenticating an identity of the UE. The UE is configured to: processing a direct communication response from the peer UE to authenticate an identity of the peer UE, wherein the direct communication response includes a signature to authenticate the identity of the peer UE. Responsive to processing a direct communication response from the peer UE to authenticate an identity of the peer UE, the UE is configured to: engage in direct communication with a peer UE.

Description

Systems, methods, and devices for secure device-to-device discovery and communication

RELATED APPLICATIONS

This application is in accordance with the benefit of U.S. provisional application No.62/132,973 filed on 2015 3, 13, of 35 u.s.c. § 119(e) claiming agency number P82920Z, which is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates to device-to-device communication, and more particularly, to secure device-to-device discovery and communication.

Disclosure of Invention

According to a first aspect of the present disclosure, there is provided a user equipment UE, comprising: circuitry configured to: receiving a discovery response message from a peer UE; generating a direct communication request to the peer UE, wherein the direct communication request includes a first signature that authenticates an identity of a user of the UE; in accordance with a determination that the discovery response message includes a payload comprising a first shared secret value, SSV, encrypting the direct communication request using the first SSV provided in the payload of the discovery response message; in accordance with a determination that the discovery response message does not include the payload including the first SSV, generating a second SSV and encoding the second SSV into the payload of the direct communication request; decrypting a direct communication response from the peer UE using the first SSV if the first SSV is included in the discovery response message or using the second SSV if the first SSV is not included in the discovery response message to authenticate an identity of a user of the peer UE based on a second signature in the direct communication response; and authenticating an identity of a user of the peer UE in response to decrypting the direct communication response from the peer UE, using the first SSV if included in the discovery response message, or using the second SSV to engage in direct communication with the peer UE if not included in the discovery response message.

According to a second aspect of the present disclosure, there is provided a mobile communication device comprising: a discovery component configured to: receiving a device-to-device discovery message comprising a first signature authenticating an identity of a source mobile communication device, and sending a discovery response message to the source mobile communication device; an authentication component configured to: verifying the identity of the source mobile communication device based on the first signature; a conversation component configured to: in response to receiving a direct communication request from the source mobile communication device, sending a message comprising a Shared Secret Value (SSV), wherein the message comprising the SSV comprises a direct communication response to establish a secure physical layer link, wherein the direct communication response comprises a second signature to authenticate an identity of the mobile communication device, and wherein the SSV is a first SSV provided in a payload of the discovery response message if the discovery response message comprises the payload containing the first SSV, and the SSV is a second SSV generated by the source mobile communication device and encoded into the payload of the direct communication request if the discovery response message does not comprise the payload containing the first SSV; and a security component configured to: encrypting or decrypting direct communication between the mobile communication device and the source mobile communication device using the SSV.

According to a third aspect of the present disclosure, there is provided a baseband processor comprising: circuitry, the circuitry comprising logic configured to: discovering one or more neighboring user equipments, UEs, based on the discovery response message; formatting a message including a payload authenticating an identity of a user corresponding to the baseband processor to transmit to at least one of the one or more neighboring UEs; in accordance with a determination that the discovery response message includes a first shared secret value, SSV, encrypting the message including the payload using the first SSV; in accordance with a determination that the discovery response message does not include the first SSV, generating a second SSV and encoding the second SSV into the payload; authenticating an identity of a user of the at least one of the one or more proximate UEs based on a signature in a message received from the at least one of the one or more proximate UEs; and in response to authenticating the identity of the user of the at least one of the one or more proximate UEs, performing direct communication with the at least one of the one or more proximate UEs to encrypt and decrypt direct messages using the first SSV or the second SSV.

According to a fourth aspect of the present disclosure, there is provided a method for direct communication, comprising: receiving a discovery response message from a peer User Equipment (UE); generating, by a User Equipment (UE), a direct communication request to the peer UE, wherein the direct communication request includes a first signature that authenticates an identity of a user of the UE; in accordance with a determination that the discovery response message includes a payload comprising a first shared secret value, SSV, encrypting the direct communication request using the first SSV provided in the payload of the discovery response message; in accordance with a determination that the discovery response message does not include the payload including the first SSV, generating a second SSV and encoding the second SSV into the payload of the direct communication request; decrypting a direct communication response from the peer UE using the first SSV if the first SSV is included in the discovery response message or using the second SSV if the first SSV is not included in the discovery response message to authenticate an identity of a user of the peer UE based on a second signature in the direct communication response; and authenticating an identity of a user of the peer UE in response to decrypting the direct communication response from the peer UE, using the first SSV if included in the discovery response message, or using the second SSV to engage in direct communication with the peer UE if not included in the discovery response message.

Drawings

Fig. 1 is a schematic diagram illustrating a communication system for providing communication services to User Equipment (UE) consistent with embodiments disclosed herein.

Fig. 2 is a schematic block diagram illustrating an example call flow for model a discovery.

Fig. 3 is a schematic block diagram illustrating an example call flow for model B discovery.

Fig. 4 is a schematic block diagram illustrating an example call flow for establishing direct communication.

Fig. 5 is a schematic block diagram showing the PC5 protocol stack.

Fig. 6A is a schematic block diagram illustrating an elliptic curve based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Fig. 6B is a schematic block diagram illustrating the Sakai-Kasahara key encryption (SAKKE) algorithm.

Fig. 7 is a schematic block diagram illustrating an example call flow for model a group member discovery consistent with embodiments disclosed herein.

Fig. 8 is a schematic block diagram illustrating an example call flow for model B group member discovery consistent with embodiments disclosed herein.

Fig. 9 is a schematic block diagram illustrating an example call flow for model a group member discovery and direct communication link establishment consistent with embodiments disclosed herein.

Fig. 10 is a schematic block diagram illustrating an example call flow for model B group member discovery and direct communication link establishment consistent with embodiments disclosed herein.

Fig. 11 is a schematic block diagram illustrating an example call flow for link establishment for direct communication consistent with embodiments disclosed herein.

Fig. 12 is a schematic block diagram illustrating an example call flow for UE-to-network relay discovery consistent with embodiments disclosed herein.

Fig. 13 is a schematic block diagram illustrating an example call flow for UE-to-UE relay discovery consistent with embodiments disclosed herein.

Fig. 14 is a schematic block diagram illustrating components of a UE consistent with embodiments disclosed herein.

Fig. 15 is a schematic diagram illustrating a mobile device consistent with embodiments disclosed herein.

Detailed Description

Detailed descriptions of systems and methods consistent with embodiments of the present disclosure are provided below. While several embodiments are described, it should be understood that the present disclosure is not limited to any embodiment, but encompasses numerous alternatives, modifications, and equivalents. Moreover, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed herein, some embodiments may be practiced without some or all of these details. Moreover, for the purpose of clarity, specific technical material that is known in the prior art has been described in detail in order to avoid unnecessarily obscuring the present disclosure.

Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include: 3 rd generation partnership project (3GPP) Long Term Evolution (LTE); the Institute of Electrical and Electronics Engineers (IEEE)802.16 standard, which is often referred to as WiMAX (worldwide interoperability for microwave access) for the industry group; and the IEEE 802.11 standard, which is often referred to as WiFi for the industry group. In a 3GPP Radio Access Network (RAN) in an LTE system, a base station may be a combination of an evolved universal terrestrial radio access network (E-UTRAN) node B (also commonly denoted as evolved node B, enhanced node B, eNodeB, or eNB) and a Radio Network Controller (RNC) in the E-UTRAN, which communicates with wireless mobile devices known as User Equipment (UE). Downlink (DL) transmissions may be communications from a base station (or eNB) to a wireless mobile device (or UE), and Uplink (UL) transmissions may be communications from a wireless mobile device to a base station.

Fig. 1 illustrates one embodiment of a communication system 100 for providing communication services to a UE 102. Communication system 100 includes E-UTRAN 104 and Evolved Packet Core (EPC)108, E-UTRAN 104 including eNB 106. UE 102 may include any type of communication and/or computing device. Example UEs 102 include telephones, smart phones, Personal Digital Assistants (PDAs), tablet computers, notebook computers, ultrabook computers, and the like. UE 102 may include multiple applications installed and running on UE 102 that may periodically communicate data through E-UTRAN 104 and/or EPC 108. The UE 102 may include devices configured to communicate using 3GPP standards (e.g., Universal Mobile Telecommunications System (UMTS), LTE-advanced (LTE-a), etc.). In some embodiments, the UE 102 may comprise a mobile wireless device configured to communicate based on any other wireless communication standard.

E-UTRAN 104 is configured to: wireless data access is provided to the UE 102 and a plurality of other wireless mobile devices. E-UTRAN 104 provides wireless data, voice, and/or other communications available through EPC 108 to UE 102, including multiple applications installed on UE 102. In one embodiment, E-UTRAN 104 operates according to a radio protocol (e.g., a radio protocol that UE 102 is capable of using). The eNB 106 may implement transmission point and RNC functionality. The eNB 106 is configured to: communicate with each other via an X2 interface, as depicted.

In addition to communicating with E-UTRAN 104 and/or EPC 108, UE 102 may also communicate directly with other mobile communication devices. Proximity-based applications and proximity services (ProSe) represent an emerging social technology trend. Proximity-based communication, which is also referred to herein as device-to-device (D2D) communication, direct communication, one-to-one communication, or peer-to-peer (P2P) communication, is a powerful technique for increasing network throughput by enabling communication between mobile stations rather than using the network infrastructure, and has wide application. For example, D2D has been proposed for local social networks, content sharing, location-based marketing, service advertising, public safety networks, mobile-to-mobile applications, and other services. D2D communications are of interest because of their ability to: reducing the load on the core network or RAN, increasing the data rate due to direct or short communication paths, providing a public safety communication path to provide other functions. The introduction of ProSe capabilities in LTE will allow the 3GPP industry to serve this developing market and at the same time serve the pressing needs of several public safety services. This combined use may enable economies of scale to be made possible, as the resulting system may be used for both public safety and non-public safety services where possible.

Various alternatives exist for implementing such direct communication paths between mobile devices. In one embodiment, the D2D air interface PC5 (i.e., the interface for D2D communication) may be implemented by some type of short range technology (e.g., bluetooth or WiFi), or by reusing licensed LTE spectrum (e.g., UL spectrum in Frequency Division Duplex (FDD) systems and UL subframes in Time Division Duplex (TDD) systems).

In one embodiment, the present disclosure relates to the 3GPP release (Rel)13 work item on proximity services, referred to as epose-Ext. See 3GPP Technical Report (TR)23.713 and TR 33.303. As part of Rel-12, 3GPP specifies mechanisms for one-to-many ProSe direct communication between one transmitting device and a group of receiving devices. As part of its Rel-13, 3GPP is continuing to work on public safety features, notably supporting ProSe direct discovery for public safety use and supporting one-to-one ProSe direct communication (between paired devices). The procedure for ProSe direct discovery is described in TR 23.713, clause 6. According to the 3GPP Rel-13 study on ProSe enhancements, there are three types of public safety discovery (see 3GPP TR 23.713). The first is UE-to-network relay discovery, the second is group member discovery, and the third is UE-to-UE relay discovery. All three types of discovery may be performed according to model a (announcement/listening) or model B (discoverer/discoveree). The terms discoveree and discoveree UE may also be referred to as target or target UE, respectively. The model a procedure includes announcing a single message (announcement) that the UE broadcasts periodically. The model B process is performed through two messages: solicitation messages (typically broadcast or multicast) and response messages (typically unicast).

As described below, TR 23.7113 shows two call flows for the specific case of group member discovery in the case of model a in fig. 2 ("i am here") and group member discovery in the case of model B in fig. 3 ("who is there.

Fig. 2 shows group member discovery in the case of model a discovery based on 3GPP TR 23.713, diagram 6.1.2.3.1-1. In this example, five UEs (labeled UE-1, UE-2, UE-3, UE-4, and UE-5) are shown. In a call flow, UE-1 (announcing UE) sends a discovery message including an indication of a message type, a discovery type, announcer information, and a ProSe UE Identifier (ID). In fig. 2, the message type is announcement, the discovery type is group member discovery, the announcer information includes information on the announcing user, and the ProSe UE ID is a link layer identifier for direct communication. In one embodiment, the announcer information includes a MAC address.

Fig. 3 shows group member discovery in the case of model B discovery based on 3GPP TR 23.713, diagram 6.1.2.3.2-1. Also, in this example, five UEs (labeled UE-1, UE-2, UE-3, UE-4, and UE-5) are shown. In the call flow, UE-1 (discoverer UE) sends a discovery message with a solicitation message type, a group member discovery type, information about any discoveree (targeted user or group of users), discoverer information about the discoverer user, and ProSe UE ID for UE-1. One or more of the discoveree UEs may respond with a discovery response message. For example, UE-2 and UE-3 respond with messages indicating the response message type, group member discovery type, discoveree information about each user, and ProSe UE ID for each UE. In one embodiment, the discoverer information includes a MAC address.

Fig. 4 shows a call flow for establishing one-to-one ProSe direct communication as described in TR 23.713, clause 7.1. For example, direct communication may be established over a secure physical layer link or layer 2 link on PC5 (see TR 23.713, clause 7.1.2.1-1). In the call flow, UE-1 sends a direct communication request message to UE-2 to trigger mutual authentication. Note that: the link initiator (UE-1) needs to know the layer 2ID or other layer ID of the peer (UE-2) in order to send a communication request. As an example, the link initiator may learn the layer 2ID or physical layer ID of the peer by first performing a discovery process or by having participated in ProSe one-to-many communication involving the peer. In response to the direct communication request, UE-2 initiates a procedure for mutual authentication. Successful completion of the authentication process completes the establishment of a secure link through PC 5. In one embodiment, the direct communication request message is part of the PC5 signaling protocol, the protocol stack of which is depicted in fig. 5 for PC5 signaling protocol. Fig. 5 is a block diagram illustrating the PC5 signaling protocol stack of fig. 7.1.1.2-1 based on TR 23.713. This example shows communication between two UEs (UE a and UE B). The PC5 signaling protocol stack includes a Physical (PHY) layer, a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, and a PC5 signaling protocol layer.

Currently, security details for both ProSe direct discovery for public safety usage and one-to-one ProSe direct communication are not currently specified. Although the current transport options for ProSe direct discovery messages have not been agreed upon, embodiments herein assume that the messages are carried via the PC5 signaling protocol, physical layer, etc.

In light of the foregoing, the present disclosure describes the use of identity-based cryptography and key agreement/agreement (agreement) in the context of ProSe direct discovery and one-to-one ProSe direct communication. When the UE is out of network coverage (i.e., when there is no real-time availability of a common root of trust), it may be desirable to use ProSe direct discovery and ProSe direct communication for public security purposes. In one embodiment, digital certificates or identity-based cryptography may be used to establish a security association (i.e., mutual authentication and key agreement) between two devices. In one embodiment, the security solution for both ProSe direct discovery and one-to-one ProSe direct communication relies on the following identity based cryptographic mechanisms: the "elliptic curve based certificateless signatures for identity based Encryption (ECCSI) signature scheme" defined in the Internet Engineering Task Force (IETF) request for comments (RFC)6507 and the Sakai-Kasahara key encryption (SAKKE) algorithm for exchanging shared secrets from sender to receiver defined in IETF RFC 6508. In one embodiment, the present disclosure proposes to apply the ECCSI signature scheme and SAKKE algorithm, respectively, on the PC5 interface (UE-to-UE) as a mechanism for mutual authentication and key agreement. Some embodiments disclose procedures and exchanged parameters as part of ProSe direct discovery and/or ProSe direct communication when identity based encryption is used.

Fig. 6A is a schematic block diagram illustrating an ECCSI signature scheme that allows a message (M) to be signed by a signing party and verified by a verifying party using identity-based cryptographic verification. In one embodiment, M may be a blank message. The signing and verifying parties have a common root of trust called the Key Management Service (KMS). The KMS possesses a KMS Public Authentication Key (KPAK) known to all users. Further, each user has a publicly known identity (e.g., in fig. 6A, ID _ s is the public identity of the signing party). In one embodiment, the use of the ECCSI signature scheme allows a signing party to claim an identity and provide proof of the identity (in the form of a digital signature). In one embodiment, the only commonality between the verifier and signer is that they require a common root of trust (e.g., credentials that can be traced back to the KMS).

Each user wishing to digitally sign their message needs to apply a pair of values to the KMS that includes a Secret Signaling Key (SSK) and a Public Verification Token (PVT). Referring to fig. 6A, the signer uses KPAK, SSK and PVT parameters to generate a digital Signature (SIGN) according to the algorithm described in ECCSI signature scheme (RFC 6507). Note that the PVT parameters are not secret and may be included inside the SIGN payload as plaintext. Upon receiving the digitally signed message, the verifier performs the verification algorithm described in RFC 6507 using KPAK and the public identity (ID _ s) of the signing party. In one embodiment disclosed herein, KPAK, SSK and PVT may be provided at configuration time rather than in real time, so that ECCSI signature schemes may be used even in out-of-coverage scenarios.

Fig. 6B is a schematic block diagram illustrating a SAKKE algorithm that allows for encrypted exchange of a shared secret key between a sender and a receiver using identity-based cryptography. Furthermore, the sender and the receiver have a common root of trust (KMS). The KMS has a KMS public key known to all users. Further, each user has a publicly known identity (e.g., in fig. 6B, ID _ r is the public identity of the recipient).

Each user wishing to decrypt a message needs to apply a Recipient Secret Key (RSK) to the KMS. Referring to fig. 6B, the sender uses the KMS public key and the public identity of the receiver (ID _ r) to encode the Shared Secret Value (SSV) according to the algorithm described in RFC 6508. The encrypted payload in fig. 6B is referred to as SAKKE payload. Upon receiving the SAKKE payload, the receiver uses the KMS public key, RSK and the receiver's public identity (ID _ r) to perform the decryption algorithm described in RFC 6508. In one embodiment, the SAKKE algorithm and payload allow a device or user to exchange a secret key that can be used for any subsequent communication of data. For example, a user or device may generate a secret key at any time and securely share with another party.

In one embodiment, it is proposed to apply the ECCSI signature scheme and/or the SAKKE algorithm to the secret key exchange for user authentication and key agreement by the PC 5. Several embodiments are disclosed that can be applied whether security mechanisms are performed during ProSe direct discovery or during establishment of direct communication, and whether model a or model B discovery is used.

In one embodiment, to enable the use of the ECCSI signature scheme and/or the SAKKE algorithm for secret key exchange, it is assumed that the UE depends on a common root of trust: KMS. In one embodiment, the KMS may be an entity located in E-UTRAN 104 or EPC 108, accessible via the Internet, or in another location. In one embodiment, each UE needs to be configured with the following information: KPAK, SSK, PVT, KMS public key, and RSK. Further, each UE may be able to use a public identity, which is used as "announcer information", "discoverer information", "discoveree information" (or alternatively, target information) or "user information for UE-x" depending on the context.

In some embodiments, it is assumed that the UE uses the same public identity (e.g., user identity) for both ECCSI signatures and SAKKE key exchanges. While this identity may be encoded in any format compatible with the guidelines provided in RFC 6509, one embodiment assumes that the identity is a concatenation of a fixed part (in the form of an International Mobile Subscriber Identity (IMSI), a Session Initiation Protocol (SIP) Uniform Resource Identifier (URI), a telephone URI (tel URI), a URI of the user @ domain type, etc.) and a varying part (in the form of a timestamp).

Fig. 7 is a diagram of a call flow 700 illustrating one example of group member discovery between an announcing UE 702 and multiple listening UEs 704, 706, 708 using model a (announcement) discovery. At 710, the announcing UE 702 periodically sends a discovery message including the following parameter settings: declaration of type; discovery type ═ group member discovery; announcer information-upper layer information about the user announcing UE 702 (this information may be used to derive the identifier ID _ s of the signatory in fig. 6A); ProSe UE ID — the link layer ID of the announcing UE 702 (ProSe UE ID may be carried in the source layer 2ID field of the MAC frame when PC5 signaling protocol is used to transmit the announcement message); and SIGN ═ ECCSI signature of the announcement message. The signature may be computed over all or a subset of the parameters in the message. In one embodiment, the signature is computed at a minimum by the announcer information parameter. Upon receiving the announcement message, one or more of the listening UEs 704, 706, 708 verify the signature payload SIGN. If the verification test is successful, one or more of the listening UEs 704, 706, 708 present the authenticated identity ("announcer information") to the respective users of the UEs. For example, the user may be given the option to allow the announcing UE 702 to discover listening UEs (e.g., UE 704).

Fig. 8 is a diagram of a call flow 800 illustrating one example of group member discovery between a discoverer UE 802 and multiple discoveree UEs 804, 806, 808 using model B discovery. At 810, a discoverer UE 802 wishing to discover nearby group members sends a discovery message including the following parameter settings: type ═ solicitation; discovery type ═ group member discovery; identifying upper-layer information of a target user or a user group; discoverer information-upper layer information about the user of discoverer UE 802 (which may be used to derive the identifier ID of the signatory in fig. 6A); ProSe UE ID — link layer ID (e.g., layer 2ID or physical layer ID) of the discoverer UE 802 (ProSe UE ID may be carried in the source layer 2ID field of MAC frame carrying solicitation message when PC5 signaling protocol is used to transmit the solicitation message); SIGN is the ECCSI signature of the solicitation message. The signature may be computed over all or a subset of the parameters in the message. In one embodiment, the signature is computed at a minimum by the discoverer information parameter.

Upon receiving the solicitation message, one or more of the discoveree UEs 804, 806, 808 check whether the message relates to them by probing the discoveree information parameters. One or more of the discoveree UEs 804, 806, 808 may verify the signature payload SIGN to determine whether the discoverer UE 802 actually corresponds to the discoverer information. If the verification test is successful, one or more of the discoveree UEs 804, 806, 808 may respond with a discovery message. Specifically, the discoveree UE 804 responds at 812 with a discovery response message that includes the following payload or settings, and the discoveree UE 806 responds at 814: type, discovery type, discoveree information, ProSe UE ID, SIGN, and SAKKE. In messages 812 and 814, the type is response. The discovery type is group member discovery. The discoveree information includes upper layer information identifying users of the respective discoveree UEs. For example, the discoveree information in messages 812 and 814 may include information identifying UEs 804 and 806, respectively. This information can be used to derive the signature ID _ s of the signing party. Note that the discoveree information in messages 812 and 814 may be different from the discoveree information in message 810. For example, the discoveree information in message 810 may refer to a group of target users, while the discoveree information in messages 812 and 814 may refer to a single discoveree user.

The ProSe UE ID includes the link layer ID of the respective discoveree UE 804, 806. For example, if the PC5 signaling protocol is used to transmit the response message, the ProSe UE ID may be carried in the source layer 2ID field of the MAC frame that is carrying the response message. SIGN includes ECCSI signatures of response messages. The signature may be computed over all or a subset of the parameters in the message, or may be computed over only the discoveree information parameters. The SAKKE includes SSVs generated by the discoveree UEs 804, 806 that have been encoded into the SAKKE payload according to the algorithm described in RFC6508 using the KMS public key and public identity of the respective discoveree UEs 804, 806. In some embodiments, the SAKKE payload is optional. If included, the SAKKE payload or SSV may be used to encrypt all future messages (e.g., MAC frames) exchanged between the discoverer UE 802 and the respective discoveree UEs 804, 806.

Fig. 9 is a diagram illustrating a call flow 900 of one example of announcing model a group member discovery between a UE 902 and multiple listening UEs 904, 906, 908, followed by establishing a security layer 2 link with the listening UE 904 for one-to-one ProSe direct communication. At 910, the announcing UE 902 periodically sends a discovery message. In one embodiment, the discovery message includes the following parameter settings: declaration of type; discovery type ═ group member discovery; announcer information-upper layer information about the user announcing the UE 902 (this information may be used to derive the identifier ID _ s of the signatory in fig. 6A); ProSe UE ID ═ layer 2ID of the announcing UE 902; and SIGN ═ ECCSI signature of the announcement message. The signature may be computed over all or a subset of the parameters in the message. In one embodiment, the signature is computed at a minimum by the announcer information parameter.

Upon receiving the announcement message, listening UE 904 verifies the signature payload SIGN. If the verification test is successful, listening UE 904 presents the authenticated identity ("announcer information") to the user of UE 904. If the user of UE 904 decides to establish a secure layer 2 link for one-to-one ProSe direct communication, UE 904 sends a direct communication request message at 912 including the following parameters: user information for UE 904, SIGN and SAKKE payload. The user information of the UE 904 includes upper layer information about the user of the UE 904. This information can be used to derive the identifier ID _ s of the signing party in fig. 6A. The SIGN may include an ECCSI signature of the direct communication request message. The signature may be computed over all or a subset of the parameters in the message. In one embodiment, the signature is computed at a minimum by the user information parameters of the UE 904. The SAKKE payload includes the SSVs generated by UE 904 and encoded into the SAKKE payload using the KMS public key and public identity that announces the UE 902 user (announcer information) according to the algorithm described in RFC 6508.

Upon receiving the direct communication request message, the announcing UE 902 verifies the signature payload SIGN. If the verification test is successful, the announcing UE 902 presents the authenticated identity ("listens for user information of the UE") to the user of the UE 902. If the user of the UE 902 decides to accept the request, the UE 902 sends a direct communication response message at 914. The direct communication response message is encrypted using a key derived from the SSV contained in the SAKKE payload received at 912. In another embodiment, the SAKKE payload may be included in the direct connection communication response at 914 rather than the direct connection communication request at 912. In this case, the direct communication response of 914 may not have been encoded based on the SSV.

Fig. 10 is a diagram of a call flow 1000 illustrating one example of model B group member discovery between a discoverer UE 1002 and multiple discoveree UEs 1004, 1006, 1008, followed by establishment of a secure layer 2 link for one-to-one ProSe direct communication. At 1010, the discoverer UE 1002 sends a discovery solicitation message. The discovery solicitation message may include the same parameters or variations discussed in connection with message 810 in fig. 8. At 1012, the discoveree UE 1004 sends a discovery response message. The discovery response message may include the same parameters or variations discussed in connection with message 812 of fig. 8. Note that including the SAKKE payload in the response message is optional and may be omitted.

Upon receiving the discovery response message 1012, the discoverer UE 1002 checks the SIGN payload. If the verification test is successful, the authenticated identity of the discoveree UE 1004 user (discoveree information) is presented to the discoveree UE 1002 user. If the user of the discoverer UE 1002 decides to engage in one-to-one communication, the discoverer UE 1002 sends a direct communication request message 1014. If the SAKKE payload is received in discovery response message 1012, discoverer UE 1002 uses the SSV provided via the SAKKE payload to encrypt the direct communication request message. If the SAKKE payload is not included in the discovery response message 1012, the discoverer UE 1002 generates an SSV and encodes it into the SAKKE payload. In response to receiving the direct communication request message 1014, discoveree UE 1004 responds at 1016 by using a direct communication response message encrypted by SSV provided inside the SAKKE payload from message 1012 or message 1014. The discoverer UE 1002 and the discoveree UE 1004 may then perform secure one-to-one device-to-device communication.

In response to receiving the discovery solicitation message 1010, the discoveree UE 1006 verifies the signature payload SIGN. If the verification test is successful, the discoveree UE 1006 presents the authenticated identity ("discoverer information") to the user of the UE 1006. If the user of UE 1006 wishes to establish a secure layer 2 link for one-to-one ProSe direct communication, UE 1006 may forego sending the response message and continue with the direct communication request message 1018. The direct communication message may include discoveree information, SIGN and/or SAKKE payload. The SAKKE payload may include SSVs encoded using the KMS public key and public identity of the discoverer UE 1002.

In response to receiving the direct communication request message, the UE 1002 verifies the signature payload SIGN. If the verification test is successful, the UE 1002 presents the authenticated identity ("discoveree information") to the user of the UE 1002. If the user of the UE 1002 decides to accept the request, the UE 1002 sends a direct communication response message 1020. The direct communication response message is encrypted using a key derived from the SSV contained in the SAKKE payload from message 1018. Alternatively, the SAKKE payload may not be included in the direct-connection communication request at 1018, but instead may be included in the direct-connection communication response at 1020.

Fig. 11 is a diagram illustrating a call flow 1100 of one embodiment of establishing a security layer 2 link for one-to-one ProSe direct communication. For example, call flow 1100 of fig. 11 may occur after an insecure discovery (e.g., no signature or SSV). UE-11102 sends a direct communication request message 1106 that includes user information for UE-11102, an ECCSI signature, and a SAKKE payload. In response to receiving the direct communication request message, the UE-21104 verifies the signature payload SIGN. If the user of the UE-21104 decides to accept the request, the UE-21104 sends a direct communication response message 1108 including user information of the UE-21104 and an ECCSI signature. If the direct connection communication request does not include a SAKKE payload at 1106, then direct connection communication response message 1108 may also include a SAKKE payload. After the direct communication response at 1108, the UE-11102 and the UE-21104 may engage in secure device-to-device communication.

In addition to the above examples, the present disclosure is also applicable to other types of D2D discovery and communication. For example, in addition to group member discovery, 3GPP TR 23.713 defines two other types of public security discovery: ProSe UE-to-network relay discovery (see clause 6.1.2.2) and ProSe UE-to-UE relay discovery (see clause 6.1.2.4). The methods, apparatus, and other teachings provided herein with respect to group member discovery may also be applied to UE-to-network and UE-to-UE relay discovery.

Currently, the messages for ProSe UE-to-network relay discovery do not contain any information about the announcement, the discoverer or the discoveree UE's user. The previously described example security solutions may still be applicable, noting that the SIGN payload may be used to digitally SIGN the message content without authenticating the user of the announcement, discoverer or discoveree UE. On the other hand, if authentication of the user of the announcer, discoverer or discoveree UE is desired, the announcement message, solicitation message and response message may be modified to include announcer information, discoverer information and discoveree information parameters, respectively.

In one embodiment, the example of fig. 11 may provide significant utility since digital signals may not be available for use as discovery signals or messages, or discovery messages may only be of a limited size. Thus, waiting until a direct communication session is established to provide SIGN or SAKKE may allow secure D2D communication without secure or authenticated discovery. On the other hand, embodiments that are able to provide signatures during discovery may be advantageous in that the identity may be verified even before the user responds to a discovery solicitation or provides a direct communication request. In one embodiment, the signature may be provided without the claimed identity. In this case, the integrity of the message may only be verified, although no proof of identity will be provided.

Fig. 12 is a diagram of a call flow 1200 for one example of enhanced UE-to-network relay discovery with model B discovery between a discoverer UE 1202 and multiple discoveree UEs 1204, 1206, 1208, 1210. Fig. 12 shows a modification of TR 23.713 map 6.1.2.2.2.1 in accordance with one embodiment. At 1212, the discoverer UE 1202 sends a solicitation message including a discovery message type, a discovery type, a Public Land Mobile Network (PLMN) ID, connectivity information, a ProSe UE ID, discoverer information, and SIGN. Note that call flow 1200 illustrates enhanced UE-to-network relay discovery, where solicitation message 1212 has been enhanced to include discoverer information and SIGN payload. At 1214 and 1216, UEs 1204 and 1206 send discovery response messages including discovery message type, discovery type, PLMN ID, connection information, ProSe relay UE ID, status, discoverer information, SIGN and SAKKE payload. Note that call flow 1200 illustrates another enhanced UE-to-network relay discovery in which response messages 1214 and 1216 have been enhanced to include discoverer information, a SIGN payload, and a SAKKE payload.

Regarding UE-to-UE relay discovery, the messages in the standard for ProSe UE-to-UE relay discovery already contain information about the announcement, the discoverer, or the users of the discoveree UEs. Thus, the previously described security solution may be applied by adding SIGN and/or SAKKE payloads to discovery messages. FIG. 13 is a diagram of a call flow 1300 showing one example of enhanced UE-to-network relay discovery in the case of model B discovery between UE-11302, UE-R1304, and UE-21306. Fig. 13 shows a modification of TR 23.713 map 6.1.2.4.2.1 in accordance with one embodiment. Specifically, message 1312 has been modified to include SIGN and message 1314 has been modified to include SIGN and SAKKE payloads. However, note also that UE-to-UE relay discovery relies on previous performance of group member discovery (indicated in fig. 13 as processes at 1308 and 1310). If a security association has been established during group member discovery, steps 1312 and 1314 may be performed in encrypted mode, in which case the SIGN and SAKKE payloads need not be used.

In one embodiment, a UE or other mobile communication device may be configured to: selectively acting as any of the UEs shown in fig. 1-13. For example, a UE may sometimes act as a discoverer UE, an announcing UE, a listening UE, or a discoveree UE, depending on the current radio environment, the needs of the user of the UE, or other variables. Accordingly, a single UE may include circuitry, computer readable code, etc., configured to implement any of the functions or methods disclosed herein.

According to an example embodiment, a first UE is configured to: a second UE is discovered and a security association is established with the second UE over the direct link. After establishing the security association, the first UE is configured to: engage in one-to-one communication with a second UE. In one embodiment, the security association includes mutual authentication and/or agreement of common key material between the first UE and the second UE. In one embodiment, the mutual authentication uses an ECCSI signature scheme. In one embodiment, the ECCSI signature payload and the UE identifier are included in a ProSe direct discovery message (announcement, solicitation, or response). In one embodiment, the ECCSI signature payload and the UE identifier are included in a signaling message (direct communication request or direct communication response) for establishing the security layer 2 link. In one embodiment, the common key material is generated by the first UE or the second UE and transmitted to the other UE using the SAKKE scheme. In one embodiment, the common key material is included as a SAKKE payload in a ProSe direct discovery message (e.g., response). In one embodiment, the common key material is included as a SAKKE payload in a signaling message (direct communication request, direct communication response) used to establish the security layer 2 link.

Referring to fig. 14, a schematic block diagram of one embodiment of a UE 1400 is shown. The UE 1400 may be capable of performing the functions of any UE disclosed herein. For example, the UE 1400 may be capable of operating as a discoverer UE, a discoveree UE, an announcing UE, a monitoring UE, or any other UE shown or discussed in this disclosure. UE 1400 includes a discovery component 1402, a session component 1404, an authentication component 1406, a security component 1408, and a communication component 1410. In one embodiment, one or more of components 1402-1410 are embodied as circuitry of a processor (e.g., a baseband processor of UE 1400). For example, the baseband processor may be sold or manufactured separately and included as part of the UE 1400 (e.g., mobile phone, tablet or MTC device). The UE 1400 or processor may comprise logic, circuitry, code, etc. that implements each of the components 1402-1410.

The discovery component 1402 is configured to: one or more neighboring UEs are discovered. In one embodiment, the discovery component 1402 is configured to: other UEs are discovered by sending or receiving discovery messages (e.g., announcement messages, solicitation messages, or response discovery messages). In one embodiment, the discovery component 1402 is configured to: a device-to-device discovery message is received that includes a signature that authenticates an identity of a source mobile communication device. In one embodiment, the discovery component 1402 is configured to: formatting a message including a payload authenticating an identity of a user corresponding to the baseband processor to transmit to at least one of the one or more neighboring UEs.

The conversation component 1404 is configured to: a direct communication session (e.g., a one-to-one ProSe session) with another device is established. In one embodiment, the conversation component 1404 is configured to: sending or receiving a direct communication request. In one embodiment, the direct communication request includes a message to establish a secure layer 2 link between the UE 1400 and the peer UE. In one embodiment, the conversation component 1404 is configured to: sending or receiving a direct communication response. For example, session component 1404 may send a direct communication response in response to receiving a direct communication request, or may receive a direct communication response in response to sending a direct communication request.

In one embodiment, the conversation component 1404 is configured to: format or prepare a direct communication request or a direct communication response that includes a signature that authenticates an identity of a sending device (e.g., UE 1400 of fig. 14). In one embodiment, the signature comprises an ECCSI signature. In one embodiment, the direct communication response may further include identification information of the user of UE 1400. Thus, the signature may be used to authenticate that the user of the UE 1400 is in fact the user corresponding to the included identification information. Similarly, the conversation component 1404 may be configured to: receiving and/or processing a direct communication request or response including one or more of an ECCSI signature and identification information of a user corresponding to the transmitting UE. In one embodiment, the direct communication request or response may be formatted or prepared to include a SAKKE payload. Similarly, the conversation component 1404 may be configured to: a direct communication request or response message is received that includes a SAKKE payload.

The authentication component 1406 is configured to: the identity of a user of at least one peer UE is authenticated. For example, authentication component 1406 may verify an identity of a user of the peer UE based on a message received from the peer UE. The message may comprise a discovery message or a direct communication request or response message. In one embodiment, the message includes a signature that may be used to authenticate the identity of the user of the peer UE. For example, the message may include the ECCSI signature discussed herein. In one embodiment, the message may include an indication of the identity of the user of the peer UE such that authentication component 1406 has sufficient information within the discovery message or direct communication request or response to verify that the peer UE is being used by a particular user. In one embodiment, authentication component 1406 can verify identity based on a public authentication key received from a key management service. In one embodiment, the public authentication key may be received from a key management service accessible via a mobile network when the UE 1400 is activated or within network coverage. In one embodiment, in response to authenticating the identity of the peer UE in response to processing the direct communication response from the peer UE, authentication component 1406 may then allow UE 1400 to engage in direct communication with the peer UE.

Security component 1408 encrypts or decrypts communications between UE 1400 and peer UEs. In one embodiment, the security component 1408 is configured to: communications with the peer UE are encrypted or decrypted based on the common key material. In one embodiment, the common key material includes a shared secret value. In one embodiment, the security component 1408 may pass and agree upon a shared secret value based on the SAKKE scheme. For example, security component 1408 can receive or transmit a shared secret value that has been encoded in the SAKKE payload. In one embodiment, the common key material is included within the direct communication request or the direct communication response as part of the SAKKE payload. In one embodiment, the SAKKE payload is included within a discovery message (e.g., a solicitation message, a response message, or an announcement message). In one embodiment, upon agreement of the common key material, security component 1408 can encode or decode communications with the peer UE using the common key material.

The communication component 1410 is configured to: communications are performed for UE 1400. For example, communications component 1404 may use one or more radios, antennas, or the like to send or receive messages. In one embodiment, the communication component 1410 may send or receive messages on behalf of the other components 1402 and 1408. In one embodiment, communications component 1404 is configured to: communicate with one or more of a peer mobile device, a base station of a wireless network, and/or any other wireless communication device.

As used herein, the term "circuitry" may refer to, be part of, or include: an application specific integrated circuit ("ASIC"), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with, one or more software or firmware modules. In some embodiments, the circuitry may comprise logic operable, at least in part, in hardware.

The embodiments described herein may be implemented as a system using any suitably configured hardware and/or software. Fig. 15 illustrates example components of a UE device 1500 for one embodiment. In some embodiments, the UE device 1500 may include application circuitry 1502, baseband circuitry 1504, Radio Frequency (RF) circuitry 1506, Front End Module (FEM) circuitry 1508, and one or more antennas 1510 coupled together at least as shown.

The application circuitry 1502 may include one or more application processors. For example, the application circuitry 1502 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled to and/or may include memory/storage and may be configured to: the instructions stored in the memory/storage are executed to enable various applications and/or operating systems to run on the system.

The baseband circuitry 1504 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1504 may include one or more baseband processors and/or control logic to process baseband signals received from the receive signal path of the RF circuitry 1506 and to generate baseband signals for the transmit signal path of the RF circuitry 1506. Baseband processing circuitry 1504 may interface with application circuitry 1502 for generating and processing baseband signals and controlling the operation of RF circuitry 1506. For example, in some embodiments, the baseband circuitry 1504 may include a second generation (2G) baseband processor 1504a, a third generation (3G) baseband processor 1504b, a fourth generation (4G) baseband processor 1504c, and/or other baseband processors 1504d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 1504 (e.g., one or more of the baseband processors 1504 a-d) may process various radio control functions that enable communication with one or more radio networks via the RF circuitry 1506. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency offset, and the like. In some embodiments, the modulation/demodulation circuitry of the baseband circuitry 1504 may include Fast Fourier Transform (FFT), preprocessing, and/or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of the baseband circuitry 1504 may include convolution, tail-biting convolution, turbo, viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

In some embodiments, the baseband circuitry 1504 may include elements of a protocol stack (e.g., elements of the Evolved Universal Terrestrial Radio Access Network (EUTRAN) protocol including, for example, Physical (PHY) elements, Medium Access Control (MAC) elements, Radio Link Control (RLC) elements, Packet Data Convergence Protocol (PDCP) elements, and/or Radio Resource Control (RRC) elements). The Central Processing Unit (CPU)1504e of the baseband circuitry 1504 may be configured to: elements of the protocol stack are run for signaling at the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry 1504 may include one or more audio Digital Signal Processors (DSPs) 1504 f. The audio DSP 1504f may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, the components of the baseband circuitry 1504 may be suitably combined in a single chip or a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the constituent components of baseband circuitry 1504 and application circuitry 1502 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 1504 may provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1504 may support communication with an evolved global terrestrial radio access network (EUTRAN) and/or other Wireless Metropolitan Area Networks (WMANs), Wireless Local Area Networks (WLANs), or Wireless Personal Area Networks (WPANs). Embodiments in which the baseband circuitry 1504 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

The RF circuitry 1506 may enable communication with wireless networks using modulated electromagnetic radiation over non-solid media. In various embodiments, the RF circuitry 1506 may include switches, filters, amplifiers, and the like to facilitate communication with the wireless network. The RF circuitry 1506 may include a receive signal path that may include circuitry to down-convert RF signals received from the FEM circuitry 1508 and provide baseband signals to the baseband circuitry 1504. The RF circuitry 1506 may also include a transmit signal path, which may include circuitry to upconvert baseband signals provided by the baseband circuitry 1504 and provide an RF output signal to the FEM circuitry 1508 for transmission.

In some embodiments, the receive signal path of the RF circuitry 1506 may include a mixer circuit 1506a, an amplifier circuit 1506b, and a filter circuit 1506 c. The transmit signal path of the RF circuitry 1506 may include a filter circuit 1506c and a mixer circuit 1506 a. The RF circuitry 1506 may further include a synthesizer circuit 1506d for synthesizing the frequencies used by the mixer circuits 1506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 1506a of the receive signal path may be configured to: the RF signal received from FEM circuit 1508 is downconverted based on the synthesized frequency provided by synthesizer circuit 1506 d. The amplifier circuit 1506b may be configured to: the downconverted signal is amplified, and the filter circuit 1506c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to: unwanted signals are removed from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 1504 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, but this is not required. In some embodiments, mixer circuit 1506a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuit 1506a of the transmit signal path may be configured to: the input baseband signal is upconverted based on the synthesized frequency provided by synthesizer circuit 1506d to generate an RF output signal for FEM circuit 1508. The baseband signal may be provided by the baseband circuitry 1504 and may be filtered by the filter circuitry 1506 c. Filter circuit 1506c may include a Low Pass Filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuit 1506a of the receive signal path and the mixer circuit 1506a of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion, respectively. In some embodiments, the mixer circuit 1506a of the receive signal path and the mixer circuit 1506a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 1506a of the receive signal path and the mixer circuit 1506a of the transmit signal path may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, mixer circuit 1506a of the receive signal path and mixer circuit 1506a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuitry 1506 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 1504 may include a digital baseband interface to communicate with the RF circuitry 1506.

In some dual-mode embodiments, separate radio IC circuits may be provided for processing signals with respect to each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuit 1506d may be a fractional-N synthesizer or a fractional-N/N +1 synthesizer, although the scope of the embodiments is not so limited as other types of frequency synthesizers may be suitable. For example, the synthesizer circuit 1506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a divider.

The synthesizer circuit 1506d may be configured to: the output frequency used by the mixer circuit 1506a of the input synthesis RF circuit 1506 is controlled based on the frequency input and the divider. In some embodiments, the synthesizer circuit 1506d may be a fractional N/N +1 synthesizer.

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by the baseband circuitry 1504 or the application processor 1502 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application processor 1502.

Synthesizer circuit 1506d of RF circuit 1506 may include a divider, a Delay Locked Loop (DLL), a multiplexer, or a phase accumulator. In some embodiments, the divider may be a dual-mode divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to: the input signal is divided by N or N +1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded and tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay element may be configured to: the VCO period is broken up into Nd equal phase packets, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, the synthesizer circuit 1506d may be configured to: a carrier frequency is generated as the output frequency, while in other embodiments the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with a quadrature generator and divider circuit to generate a plurality of signals at the carrier frequency having a plurality of different phases relative to each other. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 1506 may include an IQ/polar converter.

FEM circuitry 1508 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 1510, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 1506 for further processing. FEM circuitry 1508 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by RF circuitry 1506 for transmission by one or more of the one or more antennas 1510.

In some embodiments, FEM circuitry 1508 may include a TX/RX switch to switch between transmit mode and receive mode operation. The receive signal path of the FEM 1508 circuitry may include a Low Noise Amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuitry 1506). The transmit signal path of FEM circuitry 1508 may include: a Power Amplifier (PA) to amplify an input RF signal (e.g., provided by RF circuitry 1506); and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1510).

In some embodiments, the UE device 1500 may include additional elements (e.g., memory/storage, a display, a camera, sensors, and/or input/output (I/O) interfaces).

Examples of the invention

The following examples pertain to other embodiments.

Example 1 is a User Equipment (UE) configured to: sending a direct communication request to a peer UE, wherein the direct communication request includes a first signature that authenticates an identity of a user of the UE. The UE processes a direct communication response from the peer UE to authenticate an identity of the peer UE. The direct communication response includes a second signature authenticating an identity of a user of the peer UE. Authenticating an identity of the peer UE in response to processing a direct communication response from the peer UE, the UE engaged in direct communication with the peer UE.

Example 2 includes the UE of example 1, wherein the first signature to authenticate the identity of the user of the UE and one or more of the second signatures to authenticate the identity of the user of the peer UE comprise signatures based on a signature scheme of: an elliptic curve-based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Example 3 includes the UE of any of examples 1-2, wherein one or more of the direct communication request and the direct communication response comprise messages to establish a secure layer 2 link between the UE and the peer UE.

Example 4 includes the UE of any of examples 1-3, wherein the UE is further configured to: agreeing on common key material for communication between the UE and the peer UE, wherein the common key material is used to encode or decode communication between the UE and the peer UE.

Example 5 includes the UE of example 4, wherein the UE is configured to: agreeing on the common key material by sending or receiving the common key material to or from the peer UE, wherein the common key material is generated based on a Sakai-Kasahara Key encryption (SAKKE) scheme and communicated between the UE and the peer UE.

Example 6 includes the UE of example 5, wherein the common key material is included within the direct communication request or the direct communication response as part of a SAKKE payload.

Example 7 includes the UE of any of examples 1-6, wherein the first signature to authenticate the identity of the user of the UE and one or more of the second signatures to authenticate the identity of the user of the peer UE are calculated with one or more other parameters in a corresponding message for message integrity protection.

Example 8 is a mobile communication device, comprising: a discovery component configured to: receiving a device-to-device discovery message comprising a signature authenticating an identity of a source mobile communication device; and an authentication component configured to: the identity of the source mobile communication device is verified based on the signature and a message including a shared secret value is sent or received. The mobile communication device further comprises: a security component configured to: encrypting or decrypting one or more communications between the mobile communication device and the source mobile communication device using the shared secret value.

Example 9 includes the mobile communication device of example 8, wherein the device-to-device discovery messages include one or more of discovery announcement messages, discovery solicitation messages, and discovery response messages.

Example 10 includes the mobile communication device of any of examples 8-9, wherein the signature to authenticate the identity of the source mobile communication device comprises a signature based on a signature scheme of: an elliptic curve-based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Example 11 includes the mobile communication device of example 10, wherein the authentication component is configured to: the signature is verified based on a public authentication key received from a key management service.

Example 12 includes the mobile communication device of any of examples 8-11, wherein the message including the shared secret value includes a Sakai-Kasahara key encryption (SAKKE) payload, wherein the SAKKE payload includes the shared secret value encoded based on the SAKKE scheme.

Example 13 includes the mobile communication device of example 12, wherein the message including the shared secret value includes a direct communication request or a direct communication response to establish a secure physical layer link.

Example 14 includes the mobile communication device of example 12, wherein the message including the shared secret value comprises a discovery message.

Example 15 includes the mobile communication device of any of examples 8-15, wherein the device-to-device discovery message further includes a user identity corresponding to the source mobile communication device, wherein the authentication component is configured to: verifying the user identity based on the signature.

Example 16 is a baseband processor, comprising logic to: discovering one or more neighboring User Equipments (UEs); formatting a message including a payload authenticating an identity of a user corresponding to the baseband processor to transmit to at least one of the one or more neighboring UEs; authenticating an identity of a user of the at least one of the one or more neighboring UEs; and communicating directly with the at least one of the one or more neighboring UEs.

Example 17 includes the baseband processor of example 16, wherein the message including the payload includes one of a discovery announcement message, a discovery solicitation message, and a discovery response message.

Example 18 includes the baseband processor of example 16, wherein the message comprises a message to establish direct communication between a UE corresponding to the baseband processor and the at least one of the one or more neighboring UEs.

Example 19 includes the baseband processor of any one of examples 16-18, wherein the logic is further configured to: determining a secret key for communication between the at least one neighboring UE and a UE corresponding to the baseband processor, wherein the logic is configured to: encoding or decoding communication between the at least one neighboring UE and a UE corresponding to the baseband processor based on the secret key.

Example 20 includes the baseband processor of any of examples 16-19, wherein the payload includes an identity corresponding to a user of the baseband processor and a signature based on a signature scheme of: an elliptic curve-based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Example 21 is a method, comprising: a direct communication request is sent from a User Equipment (UE) to a peer UE. The direct communication request includes a first signature that authenticates an identity of a user of the peer UE. The method further comprises the following steps: processing a direct communication response from the peer UE to authenticate an identity of the peer UE. The direct communication response includes a second signature authenticating an identity of a user of the peer UE. Authenticating an identity of the peer UE in response to processing a direct communication response from the peer UE, the method further comprising: engage in direct communication with the peer UE.

Example 22 includes the method of example 21, wherein the first signature to authenticate the identity of the user of the UE and one or more of the second signatures to authenticate the identity of the user of the peer UE include signatures based on a signature scheme of: an elliptic curve-based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Example 23 includes the method of any of examples 21-22, wherein one or more of the direct communication request and the direct communication response includes a message to establish a secure layer 2 link between the UE and the peer UE.

Example 24 includes the method of any one of examples 21-23, further comprising: agreeing on common key material for communication between the UE and the peer UE, wherein the common key material is used to encode or decode communication between the UE and the peer UE.

Example 25 includes the method of example 24, further comprising: sending the common key material to or receiving the common key material from the peer UE, wherein the common key material is generated based on a Sakai-Kasahara Key encryption (SAKKE) scheme and communicated between the UE and the peer UE.

Example 26 includes the method of example 25, further comprising: including the common key material as part of a SAKKE payload within the direct communication request or the direct communication response.

Example 27 includes the method of any one of examples 21-26, further comprising: calculating, by one or more other parameters for message integrity protection, one or more of the first signature authenticating an identity of a user of the UE and the second signature authenticating an identity of a user of the peer UE.

Example 28 is a method, comprising: receiving a device-to-device discovery message comprising a signature authenticating an identity of a source mobile communication device; verifying the identity of the source mobile communication device based on the signature; sending or receiving a message comprising a shared secret value; and decrypting or decrypting one or more communications to or from the source mobile communication device using the shared secret value.

Example 29 includes the method of example 28, wherein the device-to-device discovery message includes one or more of a discovery announcement message, a discovery solicitation message, and a discovery response message.

Example 30 includes the method of any one of examples 28-29, wherein the signature to authenticate the identity of the source mobile communication device comprises a signature based on a signature scheme of: an elliptic curve-based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Example 31 includes the method of example 30, further comprising: the signature is verified based on a public authentication key received from a key management service.

Example 32 includes the method of any one of examples 28-31, wherein the message including the shared secret value includes a Sakai-Kasahara key encryption (SAKKE) payload, wherein the SAKKE payload includes the shared secret value encoded based on the SAKKE scheme.

Example 33 includes the method of example 32, wherein the message including the shared secret value includes a direct communication request or a direct communication response to establish a secure physical layer link.

Example 34 includes the method of example 32, wherein the message including the shared secret value comprises a discovery message.

Example 35 includes the method of any one of examples 28-34, wherein the device-to-device discovery message further includes a user identity corresponding to the source mobile communication device, wherein the method further comprises: verifying the user identity based on the signature.

Example 36 is a method, comprising: discovering one or more neighboring User Equipments (UEs); formatting a message including a payload authenticating an identity of a user corresponding to a baseband processor to transmit to at least one of the one or more neighboring UEs; authenticating an identity of a user of the at least one of the one or more neighboring UEs; and communicating directly with the at least one of the one or more neighboring UEs.

Example 37 includes the method of example 36, wherein the message including the payload includes one of a discovery announcement message, a discovery solicitation message, and a discovery response message.

Example 38 includes the method of any one of examples 36-37, wherein the message comprises a message to establish direct communication between a UE corresponding to the baseband processor and the at least one of the one or more proximate UEs.

Example 39 includes the method of any one of examples 36-38, further comprising: determining a secret key for communication between the at least one neighboring UE and a UE corresponding to the baseband processor, wherein the logic is configured to: encoding or decoding communication between the at least one neighboring UE and a UE corresponding to the baseband processor based on the secret key.

Example 40 includes the method of any one of examples 36-39, wherein the payload includes an identity of a user corresponding to the baseband processor and a signature based on a signature scheme of: an elliptic curve-based certificateless signatures for identity-based Encryption (ECCSI) signature scheme.

Example 41 is an apparatus comprising means for performing a method as in any of examples 21-40.

Example 42 includes at least one computer-readable storage medium having computer-readable instructions stored thereon that, when executed, implement the method of any of examples 21-40.

Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, non-transitory computer-readable storage media, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques in accordance with the embodiments described above. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements can be RAM, EPROM, flash drive, optical drive, magnetic disk drive, or another medium for storing electronic data. The eNB (or other base station) and the UE (or other mobile station) may further include a transceiver component, a counter component, a processing component, and/or a clock component or timer component. One or more programs that may implement or utilize the various techniques described herein may use an Application Programming Interface (API), reusable controls, and the like. These programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

It should be appreciated that many of the functional units described in this specification can be implemented as one or more components, which are terms used to more particularly emphasize their implementation independence. For example, a component may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Components may also be implemented in software for execution by various types of processors. An identified component of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component and achieve the stated purpose for the component.

Indeed, a component of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within components, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be combined into a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components may be passive or active, including agents operable to perform desired functions.

Reference throughout this specification to "an example" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in an example" in various places throughout this specification are not necessarily all referring to the same embodiment.

As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. Moreover, various embodiments may be referred to herein, along with alternatives for the various components of the various embodiments and examples of the invention. It is to be understood that these embodiments, examples and alternatives are not to be construed as being virtually identical to one another, but are to be considered as separate and autonomous representations of the invention.

Although the foregoing has been described in some detail for purposes of clarity, it will be understood that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Similarly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

It will be appreciated by those skilled in the art that many changes could be made to the details of the above-described embodiments without departing from the underlying principles of the invention. The scope of the invention should, therefore, be determined only by the following claims.

Claims (22)

1. A user equipment, UE, comprising:

circuitry configured to:

receiving a discovery response message from a peer UE;

generating a direct communication request to the peer UE, wherein the direct communication request includes a first signature that authenticates an identity of a user of the UE;

in accordance with a determination that the discovery response message includes a payload comprising a first shared secret value, SSV, encrypting the direct communication request using the first SSV provided in the payload of the discovery response message;

in accordance with a determination that the discovery response message does not include the payload that includes the first SSV, generating a second SSV and encoding the second SSV into the payload of the direct communication request;

decrypting a direct communication response from the peer UE using the first SSV if the first SSV is included in the discovery response message or using the second SSV if the first SSV is not included in the discovery response message to authenticate an identity of a user of the peer UE based on a second signature in the direct communication response; and

authenticating an identity of a user of the peer UE in response to decrypting the direct communication response from the peer UE, using the first SSV if included in the discovery response message, or using the second SSV to engage in direct communication with the peer UE if not included in the discovery response message.

2. The UE of claim 1, wherein one or more of the first signature and the second signature comprise a signature based on a signature scheme of: an elliptic curve-based certificateless signature ECCSI signature scheme for identity-based encryption.

3. The UE of claim 1, wherein one or more of the direct communication request and the direct communication response comprise messages to establish a secure layer 2 link between the UE and the peer UE.

4. The UE of any of claims 1-3, wherein the UE is further configured to: agreeing on common key material for communication between the UE and the peer UE, wherein the common key material is used to encode or decode communication between the UE and the peer UE.

5. The UE of claim 4, wherein the UE is configured to: agreeing on the common key material by sending or receiving the common key material to or from the peer UE, wherein the common key material is generated based on a Sakai-Kasahara Key encryption SAKKE scheme and communicated between the UE and the peer UE.

6. The UE of claim 5, wherein the common key material is included within the direct communication request or the direct communication response as part of a SAKKE payload.

7. The UE of any of claims 1-3, wherein one or more of the first signature and the second signature are computed over one or more parameters for message integrity protection in a corresponding message.

8. A mobile communication device, comprising:

a discovery component configured to:

receiving a device-to-device discovery message comprising a first signature authenticating the identity of the source mobile communication device, and

sending a discovery response message to the source mobile communication device;

an authentication component configured to:

verifying the identity of the source mobile communication device based on the first signature;

a conversation component configured to:

in response to receiving a direct communication request from the source mobile communication device, sending a message comprising a Shared Secret Value (SSV), wherein the message comprising the SSV comprises a direct communication response to establish a secure physical layer link, wherein the direct communication response comprises a second signature to authenticate an identity of the mobile communication device, and wherein the SSV is a first SSV provided in a payload of the discovery response message if the discovery response message comprises the payload containing the first SSV, and the SSV is a second SSV generated by the source mobile communication device and encoded into the payload of the direct communication request if the discovery response message does not comprise the payload containing the first SSV; and

a security component configured to: encrypting or decrypting direct communication between the mobile communication device and the source mobile communication device using the SSV.

9. The mobile communication device of claim 8, wherein the device-to-device discovery message comprises one or more of a discovery announcement message and a discovery solicitation message.

10. The mobile communication device of any of claims 8-9, wherein the first signature to authenticate the identity of the source mobile communication device comprises a signature based on a signature scheme of: an elliptic curve-based certificateless signature ECCSI signature scheme for identity-based encryption.

11. The mobile communication device of claim 10, wherein the authentication component is configured to: the first signature is verified based on a public authentication key received from a key management service.

12. The mobile communication device of any of claims 8-9, wherein the message including the shared secret value comprises a Sakai-Kasahara key encryption SAKKE payload, wherein the SAKKE payload comprises the shared secret value encoded based on a SAKKE scheme.

13. The mobile communication device of any of claims 8-9, wherein the device-to-device discovery message further comprises a user identity corresponding to the source mobile communication device, wherein the authentication component is configured to: verifying the user identity based on the first signature.

14. A baseband processor, comprising:

circuitry, the circuitry comprising logic configured to:

discovering one or more neighboring user equipments, UEs, based on the discovery response message;

formatting a message including a payload authenticating an identity of a user corresponding to the baseband processor to transmit to at least one of the one or more neighboring UEs;

in accordance with a determination that the discovery response message includes a first shared secret value, SSV, encrypting the message including the payload using the first SSV;

in accordance with a determination that the discovery response message does not include the first SSV, generating a second SSV and encoding the second SSV into the payload;

authenticating an identity of a user of the at least one of the one or more proximate UEs based on a signature in a message received from the at least one of the one or more proximate UEs; and

in response to authenticating the identity of the user of the at least one of the one or more proximate UEs, performing direct communication with the at least one of the one or more proximate UEs to encrypt and decrypt direct messages using the first SSV or the second SSV.

15. The baseband processor of claim 14, wherein the message comprising the payload comprises a message to establish direct communication between a UE corresponding to the baseband processor and the at least one of the one or more neighboring UEs.

16. The baseband processor of any of claims 14-15, wherein the logic is further configured to: determining a secret key for communication between the at least one neighboring UE and a UE corresponding to the baseband processor, wherein the logic is configured to: encoding or decoding communication between the at least one neighboring UE and a UE corresponding to the baseband processor based on the secret key.

17. The baseband processor of any of claims 14-15, wherein the payload comprises an identity corresponding to a user of the baseband processor and a signature based on a signature scheme: an elliptic curve-based certificateless signature ECCSI signature scheme for identity-based encryption.

18. A method for direct communication, comprising:

receiving a discovery response message from a peer User Equipment (UE);

generating, by a User Equipment (UE), a direct communication request to the peer UE, wherein the direct communication request includes a first signature that authenticates an identity of a user of the UE;

in accordance with a determination that the discovery response message includes a payload comprising a first shared secret value, SSV, encrypting the direct communication request using the first SSV provided in the payload of the discovery response message;

in accordance with a determination that the discovery response message does not include the payload that includes the first SSV, generating a second SSV and encoding the second SSV into the payload of the direct communication request;

decrypting a direct communication response from the peer UE using the first SSV if the first SSV is included in the discovery response message or using the second SSV if the first SSV is not included in the discovery response message to authenticate an identity of a user of the peer UE based on a second signature in the direct communication response; and

authenticating an identity of a user of the peer UE in response to decrypting the direct communication response from the peer UE, using the first SSV if included in the discovery response message, or using the second SSV to engage in direct communication with the peer UE if not included in the discovery response message.

19. The method of claim 18, wherein one or more of the first signature and the second signature comprise signatures based on a signature scheme of: an elliptic curve-based certificateless signature ECCSI signature scheme for identity-based encryption.

20. The method of claim 18, wherein one or more of the direct communication request and the direct communication response comprise messages for establishing a secure layer 2 link between the UE and the peer UE.

21. The method as recited in claim 18, further comprising: agreeing on common key material for communication between the UE and the peer UE, wherein the common key material is used to encode or decode communication between the UE and the peer UE.

22. The method of claim 21, further comprising: sending the common key material to or receiving the common key material from the peer UE, wherein the common key material is generated based on a Sakai-Kasahara key encryption SAKKE scheme and communicated between the UE and the peer UE.

Images