Methods and systems for communication-session arrangement on behalf of cryptographic endpoints

In an embodiment, a communication device receives a request to establish a media session with a remote endpoint. In response to receiving the request, the communication device exchanges media-session control data with the remote endpoint on behalf of a local endpoint to establish the requested media session between the local endpoint and the remote endpoint. The communication device is communicatively connected to the local endpoint via a Personal Area Network (PAN) communication link. The communication device relays media-session payload data between the local and remote endpoints. The media-session payload data (i) is associated with the media session and (ii) is encrypted based on at least one payload-data cryptographic key that is not accessible to the communication device.

BACKGROUND

People communicate wirelessly and on the go. Among the devices that make this possible are those sometimes referred to as personal mobile devices. Examples of personal mobile devices include cell phones, smartphones, walkie-talkies, and portable hotspots, among others. A personal mobile device could be handheld (as may be the case for a walkie-talkie), body-mounted, or attached to a vehicle (such as the roof of a car), as examples.

Given the relative ease with which radio signals can be intercepted, communication with (or between) personal mobile devices is often encrypted to prevent interception of the communication by third parties. Encryption is the process of converting audible voice or other data into unintelligible voice, while decryption is the process of converting the unintelligible voice back to the original audible voice. The respective algorithms used for encryption and decryption are often referred to collectively as a cipher. Examples of common ciphers include Advanced Encryption Standard (AES), Blowfish, Triple Data Encryption Algorithm (3DES), and RC4, among numerous others.

OVERVIEW

Described herein are methods and systems for communication-session arrangement on behalf of cryptographic endpoints. At least one embodiment takes the form of a method: A communication device receives a request to establish a media session with a remote endpoint. In response to receiving the request, the communication device exchanges media-session control data with the remote endpoint on behalf of a local endpoint to establish the requested media session between the local endpoint and the remote endpoint. The communication device is communicatively connected to the local endpoint via a Personal Area Network (PAN) communication link. The communication device relays media-session payload data between the local and remote endpoints. The media-session payload data (i) is associated with the media session and (ii) is encrypted based on at least one payload-data cryptographic key that is not accessible to the communication device.

At least one embodiment the form of a communication device that includes a communication interface, processor, and data storage containing instructions executable by the processor for causing the communication device to carry out at least the functions described in the preceding paragraph. Moreover, any of the variations and permutations described in the ensuing paragraphs and anywhere else in this disclosure can be implemented with respect to any embodiments, including with respect to any method embodiments and with respect to any system embodiments.

In at least one embodiment, exchanging the media-session control data takes the form of (or includes) receiving the media-session control data from the remote endpoint.

In at least one embodiment, the media-session control data includes metadata associated with the media session.

In at least one embodiment, the media-session control data includes a second cryptographic key.

In at least one such embodiment, the second cryptographic key takes the form of (or includes) a public key that is associated with a private key. In at least one such embodiment, the private key is associated with the remote endpoint.

In at least one other such embodiment, the payload-data cryptographic key is based on the second cryptographic key.

In at least one embodiment, the media-session control data includes media-session key-exchange data.

In at least one embodiment, the media-session control data includes a digital signature.

In at least one such embodiment, the digital signature takes the form of (or includes) a digital signature generated by the remote endpoint based on a private key that is associated with the remote endpoint.

In at least one other such embodiment, the digital signature takes the form of (or includes) a digital signature generated by a trusted third party.

In at least one other such embodiment, the received media-session control data further includes a second cryptographic key. The digital signature is based on the second cryptographic key. In at least one such embodiment, the digital signature takes the form of (or includes) a digital signature generated by a trusted third party based on the second cryptographic key.

In at least one embodiment, the media-session control data takes the form of (or includes) Session Initial Protocol (SIP) data. In at least one embodiment, the media-session control data takes the form of (or includes) ZRTP data. In at least one embodiment, the media-session control data takes the form of (or includes) Secure Real-time Transport Protocol (SRTP) data. In at least one embodiment, the media-session control data takes the form of (or includes) Session Description Protocol (SDP) data.

In at least one embodiment, relaying the media-session payload data includes relaying media-session payload data that includes both the media-session payload data and a digital signature that is based on the media-session payload data. In at least one such embodiment, the digital signature takes the form of (or includes) a digital signature generated by the remote endpoint based on the media-session payload data.

In at least one embodiment, the PAN communication link takes the form of a Bluetooth communication link.

In at least one such embodiment, relaying the media-session payload data takes the form of (or includes) relaying the media-session payload data between the local endpoint and the communication device via the Bluetooth communication link according to a first Bluetooth profile.

In at least one such embodiment, the first Bluetooth profile takes the form of (or includes) a Serial Port Profile (SPP).

In at least one other such embodiment, the communication device providing local-endpoint media-session control data to the local endpoint via the Bluetooth communication link according to a second Bluetooth profile that is different from the first Bluetooth profile. The local-endpoint media-session control data is based on the media-session control data. In at least one such embodiment, the second Bluetooth profile takes the form of (or includes) an Advanced Audio Distribution Profile (A2DP).

The above overview is provided by way of example and not limitation, as those having ordinary skill in the relevant art may well implement the disclosed systems and methods using one or more equivalent components, structures, devices, and the like, and may combine and/or distribute certain functions in equivalent though different ways, without departing from the scope and spirit of this disclosure.

DETAILED DESCRIPTION

The present systems and methods will now be described with reference to the figures. It should be understood, however, that numerous variations from the depicted arrangements and functions are possible while remaining within the scope and spirit of the claims. For instance, one or more elements may be added, removed, combined, distributed, substituted, re-positioned, re-ordered, and/or otherwise changed. Further, where this description refers to one or more functions being implemented on and/or by one or more devices, one or more machines, and/or one or more networks, it should be understood that one or more of such entities could carry out one or more of such functions by themselves or in cooperation, and may do so by application of any suitable combination of hardware, firmware, and/or software. For instance, one or more processors may execute one or more sets of programming instructions as at least part of carrying out of one or more of the functions described herein.

FIG. 1depicts a communication system, in accordance with at least one embodiment. As shown, a communication system100includes a communication device102, a local endpoint104, and a remote endpoint106.

Communication device102could take the form of, for example, a personal computer, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a handheld computer, a wearable computer, a personal digital assistant (PDA), a feature phone, an optical head-mounted display (OHMD), and/or a smart watch, among numerous other possibilities that will be known to those of skill in the art. In the embodiment illustrated inFIG. 1, communication device102takes the form of a smartphone.

Local endpoint104could take the form of a headset (such as a Bluetooth headset), a communication-device-mounted accessory (such as a case or sleeve), and/or any other entity capable of carrying out the local-endpoint functions described herein.

As shown inFIG. 1, communication device102is communicatively connected to local endpoint104via a Personal Area Network (PAN) communication link110. In an embodiment, the PAN communication link takes the form of a Bluetooth communication link, though the link could take other forms as well.

Remote endpoint106may be any suitable device (or combination of devices) configured to perform the remote-endpoint functions described herein. In the embodiment illustrated inFIG. 1, remote endpoint106takes the form of a remote-endpoint communication device118and a remote-endpoint accessory116that are communicatively connected via a communication link120. Accessory116, device118, and communication link120may be similar in function and/or structure to local endpoint104, communication device102, and Personal Area Network (PAN) communication link110(respectively), as examples. In other configurations, remote endpoint106could take the form of a cryptographic phone, a private branch exchange (PBX), an Internet protocol PBX (IP-PBX), and/or any other entity capable of carrying out the described remote-endpoint functions.

FIG. 2depicts a block diagram of a communication device, in accordance with at least one embodiment. As shown, communication device102includes a processor202, data storage204, a communication interface206, and a user interface208, each of which is interconnected via a system bus210. In the embodiment illustrated inFIG. 1, remote endpoint106takes the form of a cryptographic desk phone. Those having skill in the relevant art will appreciate that communication device102could have additional and/or different components, and perhaps a different arrangement of components, among many other possible variations that could be listed here.

Processor202may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a microprocessor, an application-specific integrated circuit (ASIC), and a digital signal processor (DSP).

Data storage204may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non-transitory data-storage technology deemed suitable by those of skill in the relevant art could be used.

As depicted inFIG. 2, data storage204contains program instructions210executable by processor202for carrying out various functions, though data storage204may contain different and/or additional data. In an embodiment in which communication device102is configured to carry out one or more processes and/or functions (such as the processes and functions described with reference toFIG. 1), program instructions210are executable by processor202for carrying out those functions. In instances where other entities described herein have a structure similar to that of communication device102as described in connection with at leastFIG. 3, the respective program instructions210stored by the respective data storages204of those respective devices are executable by their respective processors202to carry out functions performed by those devices.

Communication interface206may include any necessary hardware (e.g., chipsets, antennas, Ethernet cards, etc.) and/or software for conducting one or more forms of communication with one or more other components and/or entities (such as local endpoint104and remote endpoint106, as examples). Communication interface206may be configured to communicate according to one or more protocols such as Bluetooth, NFC, Infrared Data Association (IrDA), ZigBee, Wi-Fi, Universal Serial Bus (USB), IEEE 1394 (FireWire), and/or IEEE 802.3 (Ethernet)), as examples.

User interface208may include one or more displays, touchscreens, loudspeakers, microphones, dial keys, buttons, switches, light emitting diodes (LEDs), and the like. One or more user-interface components (e.g., an interactive touchscreen-and-display component) could provide both user-input and user-output functionality. And other user-interface components could be implemented in a given context, as known to those of skill in the art.

FIG. 3depicts a block diagram of a local endpoint, in accordance with at least one embodiment. As shown, local endpoint104includes a processor302, data storage304, a PAN communication interface306, a user interface308, and a cryptographic module310, each of which is interconnected via a system bus312. Those having skill in the relevant art will appreciate that local endpoint104could have additional and/or different components, and perhaps a different arrangement of components, among many other possible variations that could be listed here. Processor302, data storage304, PAN communication interface306, and/or user interface308may function in a manner similar to the similarly-named entities of communication device102, as described (for example) with respect toFIG. 2above.

Cryptographic module310may include hardware and/or software for performing cryptographic functions or processes—e.g., encryption, decryption, signature generation, signature verification, and/or key generation. In an embodiment, cryptographic module310is contained within an explicitly defined perimeter that establishes the physical bounds of the cryptographic module and that contains any processors and/or other hardware components that store and protect any software and firmware components of the cryptographic module. Cryptographic module310could take the form of (or include) a secure crypto-processor, a smart card, a secure digital (SD) card, a micro SD card, a subscriber identity module (SIM) card, and/or any other cryptographic module, as known to one of skill in the art.

FIG. 4depicts a flowchart of a method, in accordance with at least one embodiment. As shown, method400begins at step402with communication device102receiving a request to establish a media session with remote endpoint106. The media session could take the form of (or include) a telephone call and/or a video conference, among other possibilities.

Communication device102may receive the request via user interface208. For example, communication device102may receive the request as a result of a user navigating a set of one or more contacts via user interface208and then selecting a contact (or perhaps multiple contacts) with whom the user would like to establish a media session.

Additionally or alternatively, communication device102may receive the request from local endpoint104. For example, communication device102may receive the request as an audio signal representing a spoken command such as “call John.” As another example, communication device102could receive the request as a Bluetooth command instructing communication device102to establish a media session with a given contact (e.g., a contact highlighted via user interface208of communication device102).

As another possibility, communication device102may receive the request from remote endpoint106. The request could take the form of a call-origination message, a Session Initiation Protocol (SIP) message, a Real-time Transport Protocol (RTP) message, a Secure RTP (SRTP) message, a ZRTP message, a Session Description Protocol (SDP) message, an H.323 message, an Inter-Asterisk eXchange (IAX) message, and/or an IAX2 message, among many other possibilities that will be apparent to those of skill in the art.

Those of skill in the art will appreciate that communication device102may receive the request in other ways as well, including any combination of the above-provided examples. For example, communication device102could receive a SIP message from local endpoint104via a Bluetooth connection. The request could take other forms as well.

At step404, communication device102, in response to receiving the request, exchanges media-session control data with remote endpoint106on behalf of local endpoint104to establish the requested media session between local endpoint104and remote endpoint106. Exchanging the media-session control data could include receiving the media-session control data from remote endpoint106and/or sending the media-session control data to remote endpoint106, as examples. The media-session control data could take the form of (or include) SIP data, RTP data, SRTP data, ZRTP data, SDP data, H.323 data, IAX data, and/or IAX2 data, among many other possibilities that will be apparent to those of skill in the art.

FIG. 5depicts media-session control data, in accordance with at least one embodiment. As shown, media-session control data500includes metadata502, a cryptographic key504, and a digital signature506.

In at least one embodiment, metadata502takes the form of (or includes) metadata associated with the requested media session. For example, if communication device102receives the request from remote endpoint106as a SIP message that includes a SIP-message identifier, then metadata502could include the SIP-message identifier. As another example, metadata502could include a source identifier and/or destination identifier such as a telephone number, an Internet protocol (IP) address, and/or a uniform resource identifier (URI). Metadata502could take other forms as well.

Cryptographic key504could take the form of (or include) a public key that is associated with a private key. The public and/or private keys could take the form of respective RSA keys, among other possibilities that will be known to those in the art. Either or both of the private key and the public key may be associated with remote endpoint106. For example, remote endpoint106may have generated both the public key and the private key. As another example, remote endpoint106may store the private key—e.g., in a cryptographic module similar to cryptographic module310.

Instead of (or in addition to) cryptographic key504, media-session control data500could include media-session key-exchange data. The key-exchange data could take the form of (or include) components of a Diffie-Hellman key exchange, which could be used by local endpoint104and/or remote endpoint106to establish a shared cryptographic key. The key-exchange data could take other forms as well.

Digital signature506could take the form of (or include) a digital signature generated by remote endpoint106based on a private key that is associated with the remote endpoint. For example, the digital signature may be a signature generated based on a cryptographic hash of metadata502(and/or other data in media-session control data500) and further based on a private key stored in a cryptographic module of remote endpoint106. The private key could further be stored in cryptographic module310of local endpoint104(e.g., if digital signature506takes the form of a message authentication code).

Additionally or alternatively, digital signature506could take the form of (or include) a digital signature generated by a trusted third party such as a centralized certificate authority and/or a decentralized key-signing party (e.g., as in a web-of-trust authentication model). In an embodiment where media-session control data500includes both cryptographic key504and digital signature506, the digital signature may be based on the cryptographic key and may be generated by the trusted third party based on the cryptographic key.

It will be understood by those of skill in the art that media-session control data500may include different and/or additional data. For example, in some embodiments, media-session control data500may not include cryptographic key504or digital signature506. Other variations are possible as well.

At step406, communication device102relays media-session payload data between local endpoint104and remote endpoint106. The media-session payload data (i) is associated with the media session and (ii) is encrypted based on at least one payload-data cryptographic key that is not accessible to communication device102. In an embodiment, the payload-data cryptographic key takes the form of a key stored in cryptographic module310of local endpoint104, and could be a symmetric key (perhaps established using a Diffie-Hellman key exchange between local endpoint104and remote endpoint106) and/or a private key that is part of an asymmetric key pair, as examples. In another embodiment, the payload-data cryptographic key takes the form of a key stored in a cryptographic module of remote endpoint106and could be a symmetric key and/or a public key that is associated with a private key (e.g., a private key stored in cryptographic module310of local endpoint104).

In an embodiment, relaying the media-session payload data includes relaying media-session transport data that includes the media-session payload data, possibly in addition to other data.

Media-session metadata602could take the form of (or include) metadata associated with the requested media session. In some embodiments, media-session metadata take a form similar to that of metadata502associated with the requested media session. In an embodiment, media-session metadata602identifies media-session payload data604as being associated with the media session.

Payload-data metadata606could take the form of (or include) metadata associated with media-session payload data604. For example, metadata606could identify a given cryptographic key that was used to encrypt media-session payload data604and/or that may be used to decrypt media-session payload data604. Metadata606could identify a codec (e.g., an audio codec and/or a video codec) used to encode the media represented by media-session payload data604. Metadata606could include timing data and/or ordering data for respective media-session payloads of data such as media-session payload data604. Metadata606could take other forms as well.

Digital signature608may be based on media-session payload data604. To simplify generation and verification of digital signature608, the digital signature may be based on a hash (e.g., a cryptographic hash) of the media-session payload data. The hash may be generated using a hash function such as SHA-1 and/or MD5, as examples. Digital signature608may be generated by remote endpoint106based on media-session payload data604.

Relaying media-session payload data604may include relaying the media-session payload data between communication device102and local endpoint104via PAN communication link110. In an embodiment, PAN communication link110takes the form of a Bluetooth communication link, and relaying media-session payload data604between communication device102and local endpoint104via the PAN communication link takes the form of (or includes) relaying the media-session payload data via the Bluetooth communication link.

Relaying media-session payload data604via the Bluetooth communication link may include relaying the media-session payload data according to a first Bluetooth profile. The first Bluetooth profile could take the form of (or include) an Advanced Audio Distribution Profile (A2DP) and/or a Bluetooth audio profile, as examples. The media-session payload data604may be passed to local endpoint104via the Bluetooth audio profile without communication device102altering the media-session payload data. By relaying the media-session payload data according to a Bluetooth audio profile, modifications to a generic Bluetooth for enabling secure communication may be minimal.

Communication device102may provide local-endpoint media-session control data to local endpoint104via the PAN communication link. The local-endpoint media-session control may be based on the media-session control data, for example, and could include a cryptographic key (e.g., a public key), a digital signature (e.g., of a cryptographic key and/or of media-session payload data), media-session metadata, and/or payload-data metadata, among other possibilities. Such local-endpoint media-session control data may be used to by local endpoint104for encrypting and/or decrypting media-session payload data604, for example.

In an embodiment, PAN communication link110takes the form of a Bluetooth communication link and providing local-endpoint media-session control data to local endpoint104via the PAN communication link takes the form of providing the local-endpoint media-session control data via the Bluetooth communication link. Providing the local-endpoint media-session control data via the Bluetooth communication link could include providing the local-endpoint media-session control data according to a second Bluetooth profile that is different from the first Bluetooth profile. The second Bluetooth profile could take the form of (or include) a Serial Port Profile (SPP) and/or a non-audio Bluetooth profile, as examples.

Although features and elements are described above in particular combinations, those having ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements without departing from the scope and spirit of the present disclosure.