System and method for initiating protected instant messaging conversations

A system and method are provided for initiating protected instant messaging conversations. The method includes enabling a shared secret to be sent to a contact to initiate a key exchange to protect messages exchanged in an instant messaging conversation, the shared secret being sent using a communication medium other than instant messaging. After the shared secret has been sent, the method includes displaying a pending protected instant messaging conversation user interface prior to receiving a confirmation associated with receipt of the shared secret by the contact, the pending protected instant messaging conversation user interface comprising an option to resend the shared secret.

TECHNICAL FIELD

The following relates to systems and methods for initiating protected instant messaging (IM) conversations.

DESCRIPTION OF THE RELATED ART

Incorporating at least some data security into electronic communications is paramount for many organizations, particularly in regulated industries and industries in which the nature of the content of such electronic communications is sensitive or confidential.

While data security can be applied in order to provide encryption and authentication, many electronic devices are vulnerable to various attacks, either due to inadequate or lack of security.

DETAILED DESCRIPTION

While examples provided below may relate to mobile devices, it can be appreciated that the principles discussed herein are equally applicable to any electronic device capable of participating in messaging.

In one aspect, there is provided a method of operating an electronic device, the method comprising: enabling a shared secret to be sent to a contact to initiate a key exchange to protect messages exchanged in an instant messaging conversation, the shared secret being sent using a communication medium other than instant messaging; and after the shared secret has been sent, displaying a pending protected instant messaging conversation user interface prior to receiving a confirmation associated with receipt of the shared secret by the contact, the pending protected instant messaging conversation user interface comprising an option to resend the shared secret.

In another aspect, there is provided an electronic device comprising a processor, memory, and a display, the memory comprising computer executable instructions for: enabling a shared secret to be sent to a contact to initiate a key exchange to protect messages exchanged in an instant messaging conversation, the shared secret being sent using a communication medium other than instant messaging; and after the shared secret has been sent, displaying a pending protected instant messaging conversation user interface prior to receiving a confirmation associated with receipt of the shared secret by the contact, the pending protected instant messaging conversation user interface comprising an option to resend the shared secret.

In yet another aspect, there is provided a non-transitory computer readable storage medium comprising computer executable instructions for operating an electronic device, the computer executable instructions comprising instructions for: enabling a shared secret to be sent to a contact to initiate a key exchange to protect messages exchanged in an instant messaging conversation, the shared secret being sent using a communication medium other than instant messaging; and after the shared secret has been sent, displaying a pending protected instant messaging conversation user interface prior to receiving a confirmation associated with receipt of the shared secret by the contact, the pending protected instant messaging conversation user interface comprising an option to resend the shared secret.

FIG. 1illustrates a messaging environment in which various mobile devices10communicate with each other according to multiple different security policies, modes, states, or levels (hereinafter referred to commonly as “policies”). First and second mobile devices10a,10bare operating in this example according to a default, base, or lowest level policy (hereafter referred to as a “default” policy) having a lowest or baseline level of security among a plurality of policy levels. For example, the default policy can have encryption based on an encryption/decryption key stored on the mobile device10at the time of manufacture, which is common to all mobile devices10of a particular type. It can be appreciated that the default policy can include a lowest level of security or no security at all.

As shown inFIG. 1, the first and second mobile devices10a,10bcan communicate default IM messages12between each other, but have limited if any capability of communicating with mobile devices10having a higher level policy. In the example shown inFIG. 1, two additional policy levels are shown, each applying additional cryptographic protection as will be explained in greater detail below, but having different policy rules for the manner in which IM messages can be communicated. For example, a third mobile device10cis operating according to an intermediate policy which allows the third mobile device10cto communicate with other mobile devices10that are operating according to a policy level that is higher than the default policy using protected IM messages14, e.g., a further mobile device10d. The third mobile device10ccan communicate with the first mobile device10a(or second mobile device10b) using default messages12, namely messages that utilize the default cryptographic protocols, in which case the additional or strengthened security is not utilized. The fourth mobile device10din this example is subjected to a highest policy level and can only communicate with other mobile devices10that are capable of exchanging protected IM messages14, for example only the third mobile device10cinFIG. 1. It can be appreciated that a policy can include multiple different levels with that policy. For example, one policy level can be used for assigning a level of encryption, and another policy level can be used for indicating whether or not the user can message a contact having a lower level of encryption.

The intermediate policy can be applied by organizations or individuals that wish to be able to exchange protected IM messages14in appropriate circumstances, e.g., when communicating sensitive content with work colleagues. The highest restriction level can be applied by organizations who wish to completely limit communications for that particular device under all circumstances, e.g., for government employees or those in a highly regulated industry.

It can be appreciated that the number of policy levels shown inFIG. 1is for illustrative purposes only. For example, two policy levels may be used in which a default policy level and one additional higher security level are available. Similarly, more than three policy levels may be used, e.g., to provide a gradient of cryptographic security according to the applied policy level.

An example of a default level of cryptography used to generate default IM messages12is illustrated inFIG. 2. In the messaging scenario depicted inFIG. 2, a first mobile device10aexchanges messages with a second mobile device10bvia a messaging infrastructure18(e.g., PIN-based messaging as illustrated inFIGS. 34-36below). The first mobile device10acommunicates over at least one first network16a(e.g., WiFi, cellular, Internet, etc.) in order to have the messaging infrastructure18facilitate delivery of messages to the second mobile device10bover at least one second network16b. A policy authority20is in communication with the first and second mobile devices10a,10bto facilitate the provision of keys and/or keying material, digital certificates, etc. Two security mechanisms are used in the default scenario shown inFIG. 2, namely encryption24and transport security22. For example, the transport security22can be applied using transport layer security (TLS) or similar protocols such as secure sockets layer (SSL), a TLS predecessor. The messaging infrastructure18may also use a user identifier (ID) to perform authentication, e.g., using a single sign-on identity service. The user identifier can also be tied to a device ID, e.g., a PIN). The encryption24can be applied using any suitable cryptographic protocol. For illustrative purposes, each mobile device10can store a symmetric messaging encryption key, which is used to encrypt and decrypt messages exchanged with other mobile device10, e.g., a symmetric-key block cipher such as a Triple Data Encryption Standard (DES) key having a desired key size. The symmetric messaging encryption key can also be used to authenticate received default messages12. As noted above, the symmetric messaging encryption key can be a global encryption key added to each mobile device10at the time of manufacture to ensure each device is capable of exchanging default messages12and thus utilize at least a default level of security.

When implementing multiple levels of security, the policy authority20can be used to issue, revoke, renew, and otherwise manage security policies for the mobile devices10. The policy authority20can be a third party service such as an application server or storefront, or can be implemented at an enterprise level where IT policies are controlled within an enterprise.

The relatively more secure cryptography applied to protected IM messages14is illustrated inFIG. 3. As can be seen inFIG. 3, in addition to encrypting messages using the default encryption24and applying transport security22, an additional cryptographic mechanism26is utilized to further protect confidentiality and data integrity. The additional cryptographic mechanism26can be selected according to any desired or imposed security regulations, guidelines, standards, etc. In the present example, elliptic curve cryptography (ECC) is utilized, for example an Elliptic Curve Password-Authentication Key Exchange (EC-SPEKE) to securely exchange a symmetric key by protecting the exchange using a password, a key derivation function (KDF) to securely derive message keys from shared secrets, messaging signing using the Elliptic Curve Digital Signature Algorithm (ECDSA), and a one-pass Elliptic Curve Diffie-Hellman (ECDH) protocol to derive new shared secrets between two correspondents using a private key of one correspondent and a public key of the other. It can be appreciated that such an additional cryptographic mechanism26is illustrative and various other cryptographic mechanisms26can be used to utilize protected IM messages14.

One example for utilizing protected IM messages14will now be described by way of example, in which the mobile device10may utilize a default policy or a “protected” policy. Each mobile device10that is subjected to the protected policy utilizes two long-term public/private key pairs that are static for the device and associated user, namely an encryption key pair and a signing key pair. To communicate protected IM messages14, the mobile device10creates a pair-wise key with each contact that is also using the protected policy. For one-to-one communications, the pair-wise key can be considered a session key. The session key is used to encrypt all messages within an IM conversation. The pair-wise key is derived from the initiator's private encryption key and the recipient's public encryption key, e.g., using one-pass ECDH. Each session key is combined with unencrypted (but signed) keying material in the protected IM message14to produce a message encryption key. The message encryption key is derived from the keying material and session key, using a KDF.

FIG. 4illustrates an example of an ECDH key exchange process. The key exchange process is used to establish contact-specific keys for each IM contact with which a particular mobile device10wishes to communicate in accordance with the protected policy. In order to exchange keys, the parties exchange a shared secret (referred to hereinafter as a “pass phrase”, which illustrates one example of such a shared secret) using an out-of-band communication channel, i.e., using a communication medium other than the messaging infrastructure18used to conduct IMing. For example, the out-of-band mechanism can include email, SMS, telephone, manual delivery (in person), short-range communications (e.g., NFC, WiFi, Bluetooth, infrared, etc.), etc. The shared secret can be generated in various ways, for example, using an auto-generated pass phrase. As discussed below, the pass phrase can be editable and/or can be user-supplied. It can also be appreciated that the pass phrase can be utilized in its original format, or can be converted to another format such as binary, hexadecimal, etc. The out-of-band exchange makes malicious third party attacks more difficult since such a third party should not know when or how the secret will be shared. The attacker would need to intercept both connectivity over the messaging infrastructure18and the out-of-band channel used for the shared secret exchange in order to compromise the key exchange. The use of an out-of-band channel can also enable the messaging infrastructure18to be removed from the key management process, thus allowing further flexibility for enterprise and individual entities.

The key exchange process shown inFIG. 4begins with correspondent A generating the encryption and signing key pairs at1aand correspondent B generating encryption and signing key pars at1b. In this example, correspondent A is the initiator and sends a shared secret (e.g., pass phrase) at step2using an out-of-band communication channel. After sending the shared secret, correspondent A sends a first IM message12at step3using the messaging infrastructure18, which can be considered an invitation to begin a “protected” chat or conversation. The invitation can include contact information and an indication of the highest protocol version the associated mobile device10supports. Correspondent B in this example responds to the invitation at step4with an acceptance, including an indication of the highest protocol version they support, proof that correspondent B knows the secret password (i.e., an indication that the user or device has entered or accepted entry of the supplied shared secret), and correspondent B's long-term public encryption and public signing keys. Correspondent A then responds to the acceptance at step5with proof that correspondent A knows the secret password (i.e. to prove that another party did not supply the shared secret), correspondent B's long-term public encryption and public signing keys, and proof that correspondent A has the private keys corresponding to the public keys they claim to own, e.g., by performing a verifiable cryptographic operation using the private keys. Similarly, at step6, correspondent B sends proof to correspondent A of ownership of the public keys they have provided. Once correspondent A verifies the proof sent in step6, both parties know each other's public keys and that they belong to an entity that also knows the corresponding private keys, and an entity that knows the correct shared secret. At steps7aand7b, the correspondents A, B can begin exchanging protected IM messages14.

Once the key exchange process has been completed, e.g., as shown inFIG. 4, the mobile devices10use the long-term signing and encryption key pairs to digitally sign and encrypt respectively a protected IM message14, and to perform the complementary cryptographic processing for received messages.FIG. 5illustrates an example of cryptographic processing applied to outgoing protected IM messages. In this example, both a message key and a session key are used, wherein the session key is a symmetric key shared by all conversation participants, and is established with a one-pass ECDH using the contact's public encryption key. At step1, a message key is established with the KDF for each new message, using the session key and unique per-contact keying material. The unencrypted message is then encrypted using the symmetric message key at step2to generate an encrypted message, which is combined with the keying material at step3to recreate the message key in the unencrypted portion of the message being generated. The combined keying material and encrypted message is then hashed at step4(e.g., using SHA2-512), and the hash is signed at step5using the sender's private signing key, e.g. using ECDSA. The digital signature, keying material, and encrypted message are then wrapped into a message envelope at step6to generate a protected IM message14, and the protected IM message14is passed to the transport layer at step7(e.g., to send the message using TLS).

FIG. 6illustrates an example of cryptographic processing applied to incoming protected IM messages14. The encrypted message envelope containing or otherwise corresponding to the protected IM message14is received and is processed at step1to parse the envelope and separate the digital signature from the keying material and encrypted message. The digital signature is decrypted using the sender's public signing key to obtain the message hash at step2. The message hash is compared to a locally computed hash to determine if they match. If so, the recipient confirms that the sender sent the message (since only the sender has the private signing key corresponding to the public signing key), and that the message has not been altered (since the hashes match). The message hash and the digital signature are used at step3to verify the message signature using the sender's public key to determine whether or not the message is authentic. The message key is then derived at step4from the session key and the unencrypted keying material. The message is used at step5to decrypt the message, e.g., using AES in CTR mode in the examples discussed above.

As discussed above, the protected policy can be utilized in an enterprise environment30, an example of which is shown inFIG. 7. The enterprise environment30includes an enterprise server32and one or more corporate servers (e.g., mail server)36behind a corporate firewall34which enables individuals within the enterprise to communicate using the Internet and wireless networks16, using mobile devices10and other computing devices38. The enterprise server32can be used to deploy the protected policy, e.g., by pushing the policy out to enterprise devices. In this way, the enterprise server32can be used to enforce a higher level of security to be used by devices within the enterprise.

Turning now toFIG. 8, an example of a configuration for a mobile device10is shown. The mobile device10includes one or more communication interfaces46to enable the mobile device10to communicate with other devices, services, and domains, e.g. to communicate via one or more networks16as shown inFIGS. 2 and 3. The one or more communication interfaces46in this example generally represents any one or more short-range, wide-area, wired, or wireless communication connections utilizing a connection/connector/port, wireless radio, etc. The mobile device10also includes a display component48, which may be used by various applications and services on the mobile device10including an IM application50in the example shown inFIG. 8. The IM application50is also configured to utilize the one or more communication interfaces46to enable “IMing” on the mobile device10.

The IM application50includes or otherwise has access to a protected IM module52for enabling participating in protected IM conversations56with other protected devices, as well as to participate in default IM conversations54with devices not subject to a protected policy. An IM storage58may therefore be included or otherwise accessible to the IM application50for storing protected IM conversations56, default IM conversations54, and the various cryptographic keys (and/or keying material) as discussed above. The cryptographic keys60would include a pair-wise key for each contact associated with the IM application50which can also communicate according to a protected policy. It can be appreciated that the delineation between components shown inFIG. 8is for illustrative purposes and various other configurations are possible. It can also be appreciated that the allocations of memory storage are shown for illustrative purposes and various separate memory allocations and/or devices may be used, e.g., to securely store cryptographic keys in a hardware security module or other higher security component.

An example of a protected IM conversation user interface (UI)100is shown inFIG. 9. The protected IM conversation UI100includes a badge108or icon or other identifying feature in an input field104as well as the text “Protected Chat”106in order to identify the protected IM conversation UI100as being related to a protected conversation with a contact who is also subjected to a protected policy. It can be appreciated that other visual identifiers can be used such as different text colors, different fonts, border coloring, background coloring, etc. Moreover, the badge108could be placed in other locations within the UI100, such as in a header portion near the avatar and contact name.FIG. 10illustrates a default IM conversation UI100′, which does not include the badge108or text106, but instead uses the text “Enter Message”110to differentiate between default and protected conversations. The protected IM conversation UI100is used subsequent to performing a key exchange with the corresponding contact, e.g., as shown inFIG. 4.

FIG. 11illustrates an enlarged view of the input field104during message composition. In view (a), the badge108and “Protected Chat” text106are shown. When the input field104is selected for typing, the badge108and text106are removed as shown in view (b) to enable the message to be composed. After sending the composed message, the badge108and text106may be reinstated as shown in view (c). It can be appreciated that while the badge108is removed, the text being typed into the input field104can be changed (with respect to default text) to incorporate a consistent color to further extend the “protected” connotation when the badge108is removed. It can also be appreciated that in other examples the badge108can be caused to remain in the input field104at all times.

As shown inFIG. 12, the input field104can also be used to provide status notification text116.FIG. 13illustrates a specific example wherein the status notification116′ includes the text “Awaiting Pass Phrase” while the pass phrase (shared secret) is awaiting confirmation from the contact, details of which will now be described making reference toFIGS. 14 through 31.

FIG. 14illustrates a chats list UI200which includes a number of chat list entries202each corresponding to an IM conversation with an IM contact. In the example shown inFIG. 14, both protected and default IM conversations are listed together and without distinguishing between the two types of chats. However, it can be appreciated that separate chat lists could also be used, or a distinguishing feature applied to either the default or protected chats (e.g., color, font, badge, etc.). It can be appreciated that other IM UIs can also be modified to include distinguishing features applied to either the default or protected chats, e.g., contact lists (listing contacts), notifications/updates lists, etc. Moreover, the various IM UIs shown and/or discussed herein can be updated to include status information regarding key exchanges, pass phrase exchanges, invitation exchanges, and other processes involving communications between the mobile device10and one or more contacts. By selecting the list entry204associated with Contact A as shown inFIG. 14, a pending protected IM conversation UI210is displayed as shown inFIG. 15, in which a pass phrase entry dialog212is provided. The pass phrase entry dialog212includes an explanatory message214to instruct the user as to the purpose of the pass phrase and procedure for beginning a protected chat. The pass phrase entry dialog212also includes an pass phrase entry field216, for entering a pass phrase218. The pass phrase218can be automatically generated and populated by the IM application50, or can be created and/or edited by the user, e.g., by selecting the pass phrase entry field216to begin typing as illustrated with the provision of a cursor220inFIG. 15. By selecting a cancel button222the protected chat initiation (and thus key exchange with Contact A) can be aborted. By selecting a next button224, the pass phrase is sent to Contact A to initiate the key exchange process.

In some examples the user can be provided with an opportunity to select from a plurality of available out-of-band communication channels, for example, if permitted by the protected policy and if available on the mobile device10.FIG. 16illustrates a contact type selection dialog230that is displayed after selecting the next button224. The contact type selection dialog230includes a list232of available contact types, which can identify the communication medium and/or an associated address (e.g., phone number, email address, etc.). In this example, an entry234for Contact Type 2 is selected, which includes an email address236, namely “first.last@email.com”. A cancel button238is also provided to enable the send pass phrase process to be aborted. By selecting the entry234as shown inFIG. 16, an email message composition UI250is displayed as shown inFIG. 17A. It can be appreciated that for other contact types, other corresponding message composition UIs would be displayed. It can also be appreciated that a default message may be sent automatically to thereby skip the message composition step.

The email composition UI250includes a “To” entry field252that is, in this example, pre-populated with the selected email address236. If Contact A has more than one email address in an associated contact details, other mechanisms can be utilized to allow the user to select from one of a plurality of available addresses. Similarly, if an email address is not stored, or the user wishes to use a different email address, the “To” entry field252can be used to manually enter an address. A subject line254is also pre-populated in this example to identify the email message as being related to the IM protected pass phrase process. The content258of the email message is also pre-populated with an invitation message256. The invitation message256indicates what the pass phrase218is, and may optionally include a link260to direct the recipient to a pass phrase entry UI (described below).

While the example shown inFIGS. 15,16, and17A illustrate the provision of a shared secret using an out-of-band passphrase delivery, it can be appreciated that other mechanisms for mutual authentication can be used, such as a challenge/response mechanism, captcha mechanism, biometric (e.g., fingerprint), image selection, etc.FIG. 17Billustrates one such example wherein the message composition UI250includes a challenge question256′ to be sent to the selected address, in this example “What Color are my Eyes?”. A link260′ can also be provided in this scenario, which when selected displays a UI for entering a response to the challenge. The challenge question can be generated automatically or can be user-supplied.FIG. 17Cillustrates yet another example in which the shared secret is provided using a QR code270which can be displayed by User to Contact A to initiate the key exchange and begin a protected chat. As shown inFIG. 17C, the QR code270can be displayed with an instructional message272indicating how to use the QR code270to provide the shared secret. It can be appreciated that options can be provided to utilize a plurality of mechanisms for sharing the shared secret. For example, User may be provide with an option to use a pass phrase218via a communication, or a QR code scan or other short-range mechanism such as an NFC tap.

After sending the pass phrase218(or other form of shared secret), the pending protected IM conversation UI210is updated to provide the user with useful information regarding the status of the pass phrase provision and underlying key exchange process. InFIG. 18, a message content portion280of the pending protected IM conversation UI210is updated to include a first notification message282indicating that the pass phrase218has been sent, and which contact address was used. This allows the user to determine after the fact how the pass phrase was sent in case they wish to retry with a new address or to remind the contact of the pending confirmation. To further assist the user, a check mark284or other visual indicator can be used to signify that the pass phrase was sent. Since the pass phrase was sent using an out-of-band channel, an indication of whether the message was delivered and/or received would require communication between the IM application50and the corresponding out-of-band application. A first timestamp283is also displayed with the first notification message282to enable the user to determine how long it has been since the pass phrase was sent to Contact A.

As also shown inFIG. 18, a resend button286is embedded or otherwise included in the pending protected IM conversation UI210to allow the user to initiate a resending procedure. For example, the user may select the resend button286to send a new pass phrase to a different email account or using a different communication medium. It can be appreciated that to maintain security, the pass phrase should only be used once and selection of the resend button286should trigger generation of a new pass phrase or otherwise enable selection or composition of a new pass phrase, e.g., by returning to the UI shown inFIG. 15. It can be appreciated that the notifications and resend button286can also be included for other exchange mechanisms such as a challenge/response.

The message content portion280can also be used to display other types of notifications, such as an unsuccessful delivery message288as shown inFIG. 19. For example, if the pass phrase is sent when a server or system is unavailable or the mobile device10is out-of-coverage for at least the corresponding out-of-band channel, the user may be notified conveniently within the pending protected IM conversation UI210. Similar to what is shown inFIG. 18, the resend button286can be displayed while the protected conversation establishment is pending to allow the user to resend a new pass phrase, e.g., using a different address or medium. For example, the pass phrase may be unsuccessfully delivered if an incorrect email address is used which “bounces back” to the mobile device10. In such a scenario, the user would be able to resend the pass phrase and correct the error. Although not shown inFIG. 19, the address used in the unsuccessful attempt can also be displayed to enable the user to ascertain whether or not there was an error in the address used.

After sending the pass phrase, notifications can be populated in other UIs. For example, as shown inFIG. 20, the list entry204for Contact A in the chats list UI200, in addition to displaying the contact name300can provide a status notification302associated with the pass phrase, in this example: “Awaiting pass phrase confirmation”. In this way, the user can ascertain whether or not they may begin a protected chat without having to necessarily select and display the pending protected IM conversation UI210.FIG. 21illustrates the same list entry204upon receiving confirmation of the pass phrase from Contact A. In this example, the contact name300′ is highlighted similar to when a new message is received to draw attention to the associated updated notification304′ which indicates: “Pass phrase confirmed. Chat now protected”. The user may then access the pending protected IM conversation UI210by selecting the list entry204to display a new protected IM conversation UI100as shown in, for example,FIG. 29.

Turning now toFIG. 22, the pending protected IM conversation UI210can also be periodically updated to provide additional status notifications, e.g., a second status notification310and second time stamp312in the message content portion280. The second status notification310in this example indicates that the contact has not yet confirmed the pass phrase. The second time stamp312allows the user to determine how long the pending confirmation has taken so far, in order to determine whether or not to use the resend button286which is again displayed in the message content portion280. As noted above, the pending protected IM conversation UI210can also be updated to include additional information to inform the user of the progress of the pass phrase or other data and information exchanges with the contact.

FIG. 23illustrates an IM chats list UI320for Contact A, which includes a list entry324associated with “User”, namely the initiator of the pass phrase process. Similar to what is shown inFIG. 21, a contact name326associated with the sender of the pass phrase218can be highlighted in a manner similar to a conversation with a newly received message. A notification328can also be provided, in this example indicating: “Select to confirm pass phrase”. By selecting the list entry324, a pending protected IM conversation UI350for the recipient is displayed as shown inFIG. 24. The pending protected IM conversation UI350also displays a recipient pass phrase entry dialog352that includes an instruction message354indicating that the pass phrase was sent using another communication channel and in this example that the pass phrase is not case sensitive. An input field356is provided to enable the recipient user to enter the pass phrase. A cancel button358is provided to allow the recipient user to abort the pass phrase provision process. A save button360is also provided, which can be kept inactive as shown inFIG. 24until a pass phrase is entered, as shown inFIG. 25. InFIG. 25a recipient-entered pass phrase218′ is provided in the input field356and the save button360becomes active to allow the recipient to submit the pass phrase218′.

The pass phrase218′ can also be automatically populated and the pending protected IM conversation UI350accessed from the received invitation message.FIG. 26illustrates an example of an email message UI370which includes a subject line372and message374corresponding to what was composed and sent by the initiator. As indicated above, a link376can be embedded into the invitation message374. By selecting the link376, the entry dialog352shown inFIG. 25can be automatically displayed, and can include a pre-populated input field356with the supplied pass phrase218′ to minimize the steps used to confirm the pass phrase and thus minimize interruptions experienced by the recipient. As discussed above, the pass phrase can be provided using various out-of-band channels, including using personal interactions between the initiator and the recipient. For example, the pass phrase or other secret can be exchanged transparently to the user using a QR scan, NFC tap, etc.

After confirming the pass phrase218′, using which ever mechanism the recipient uses, a new protected chat UI350for the recipient, with “User” (i.e., the initiator) is displayed as shown inFIG. 27, which can thereafter be used to conduct a protected conversation between User and Contact A.

Various other notifications can be utilized to convey the status of the pass phrase process. For example, as shown inFIG. 28a unified or amalgamated inbox or message repository, hereinafter a message “hub” UI400is shown, which includes various list entries402, which may include, for example, incoming or outgoing messages from a plurality of different messaging or communication media, notifications, updates, alerts, missed phone calls, etc. In the example shown inFIG. 28, an IM list entry404corresponding to the pending protected IM conversation UI210with Contact A is shown, in which the contact name406is highlighted to indicate a new message, and a notification408is provided, indicating: “Pass phrase confirmed. Chat is now protected”. Similar to the UI flow described above with respect to the IM chats list UI200, by selecting the list entry404, the now-enabled protected IM conversation UI100is displayed as shown inFIG. 29to enable the user to begin the protected conversation.

The message hub UI400can also be used to provide other types of notifications, as shown inFIG. 30in which a list entry420includes a notification that is distinct from identifying pass phrase confirmation as shown inFIG. 28. In this example, the list entry420includes a notification badge426, a contact name422(highlighted when unread/unattended), and a notification message424, indicating: “Contact has not yet confirmed pass phrase”. It can be appreciated that similar notifications can be provided at the recipient's end. For example, as shown inFIG. 31, a recipient message hub UI450may also include a notification list entry452that includes a notification badge458, an indication of the sender by way of a contact name454in this example, and a notification message456, in this example: “Pass phrase needed for IM protected chat”.

FIG. 32illustrates computer executable operations performed by an initiator in initiating a protected chat using the pass phrase218. At500the IM application50detects the initiation of a new protected chat, e.g., by detecting selection of a contact that is known to also by under the protected policy. The IM protected module52may then be utilized to perform the pass phrase process by enabling the pass phrase to be selected (i.e. pre-populated text confirmed or text to be entered) and sent in an out-of-band channel at502. The IM protected module52can also enable the user to select from multiple available out-of-band channels at504and enable a message to be composed at506. It can be appreciated thatFIG. 32assumes that the pass phrase exchange proceeds through the illustrated steps but that “cancel” options can be provided to abort the process at any of these stages as illustrated in the UIs. The IM protected module52then determines at508whether or not the composed invitation message has been selected to be sent. Once it has been selected to be sent (e.g., by selecting the send button262), the message is sent at510as an invitation to enter a protected chat.

After sending the invitation, one or more UIs can be updated at512, e.g., as discussed above to indicate that the pass phrase has been sent, including providing a notification in the pending protected IM conversation UI210. While waiting for the pass phrase to be confirmed, the IM protected module52determines at514whether or not to resend the pass phrase, e.g., if detecting selecting of the resend button286. If so, the process may repeat from502. If not, the IM protected module52determines at516whether or not to provide an additional notification, e.g. by adding another notification message to the pending protected IM conversation UI210and repeating512. The IM protected module52also determines at518whether or not the pass phrase has been confirmed by the recipient contact, e.g., by looking for received messages or other data indicating the pass phrase was successfully entered by the recipient. Once confirmed, the key exchange process is completed at520, which should be performed transparently to the user, and the protected chat is enabled at522.

FIG. 33illustrates computer executable operations performed by a recipient contact in participating in the pass phrase process to establish the key exchange. At600the recipient mobile device10receives the pass phrase218in an out-of-band communication, e.g., via email. The IM application50and/or IM protected module52may also provide one or more notifications to the recipient at602, e.g., in a message hub, chats list, etc. The IM protected module52at the recipient then enables the pass code to be entered at604and determines at606whether or not the correct pass phrase has been saved. If not, re-entry (e.g., up to a predetermined number of times) can be performed by repeating604. Once successfully saved, the UIs for the IM application50are updated at608, e.g., to enable the protected chat UI to be accessed via a notification, and the key exchange is completed at610, which should be transparent to the user. The protected chat with the initiator contact is then enabled at612.

Accordingly, it can be seen that the pass phrase exchange and confirmation process can be made convenient to the user by incorporating various notifications both within and outside of the pending protected IM conversation UI210, and be enabling the user to conveniently resend a pass phrase218if desired.

For illustrative purposes, an example of a communication system including a messaging infrastructure18that enables mobile devices10a,10bto communicate via an IM (or other P2P-type) messaging system700over a wireless network16, is shown inFIG. 34. It will be appreciated that the mobile devices10a,10bshown inFIG. 34are shown as such for illustrative purposes and many other mobile devices10(not shown) may also be capable of communicating with or within the communication system. It will also be appreciated that although the examples shown herein are directed to mobile communication devices, the same principles may apply to other devices capable of communicating with the IM system700. For example, an application (not shown) hosted by a desktop computer or other “non-portable” or “non-mobile” device (e.g., computer38shown inFIG. 7) may also be capable of communicating with other devices (e.g. including mobile devices10) using the IM system22.

The IM system22is, in this example, a component of the messaging infrastructure18associated with the wireless network16. The messaging infrastructure18in this example includes, in addition to the IM system22, and among other things not shown for simplicity, a personal identification number (PIN) database702. The PIN database702in this example embodiment is used to store one or more PINs associated with respective mobile devices10, whether they are subscribers to a service provided by the messaging infrastructure18or otherwise.

A first mobile device10amay communicate with a second mobile device10band vice versa via the IM system700, in order to perform IM messaging or to otherwise exchange IM-based communications. For ease of explanation, in the following examples, any IM-based communication may also be referred to as a IM message12,14as shown inFIG. 34. It can be appreciated that only two mobile devices10a,10bare shown inFIG. 34for ease of illustration and, for example, in an electronic group conversation, three or more mobile devices10would be participating in the group conversation. The IM system700in the example shown is configured to facilitate communication of both regular or default IM messages12utilizing a first level of security, and protected IM messages14, utilizing a second level of security that is higher than the first level of security as discussed above by way of example. For example, the IM system700can identify from information included in the messages12,14whether the message is a regular IM message12or a protected message14for the purpose of determining how to store a copy of the message12,14.

In some example embodiments, the IM system700may be capable of sending multi-cast messages, i.e. forwarding a single message from a sender to multiple recipients without requiring multiple IM messages12,14to be generated by such a sender. For example, as shown inFIG. 35, the IM system700can be operable to enable a single IM message12,14to be sent to multiple recipients by addressing the IM message12,14to multiple corresponding IM addresses, and having the IM system700multicast the message12,14to those recipients.

An example of a IM message12,14is shown in greater detail inFIG. 36, and has a format that is particularly suitable for a PIN-to-PIN based system. In a typical IM protocol, each IM message12,14has associated therewith a source corresponding to the mobile device10which has sent the IM message12,14and includes a destination identifying the one or more intended recipients. Each IM message12,14in this example includes a body720, which contains the content for the IM message12,14(e.g. text, audio, images, video, or other data), and a header710, which contains various fields used for transmitting and processing each IM message12,14. In this example, the header30includes a message type field730to specify the type of transmission (e.g. chat, registration, block, presence, etc.), a source field732to specify the device address for the sender, a destination field734to specify the device address(es) for the one or more intended recipients, an ID field736to identify the corresponding IM application (e.g., see IM application50inFIG. 8) and a timestamp field738to indicate the time (and if desired, the date) at which the IM message12,14was sent by the designated sender. The message type field730may be used to designate whether the message12,14is a regular IM message12or a protected IM message14. However, the ID field740could also be used with a particular ID type being recognizable as a protected-type message14. Another field could also be added to the header710to indicate protected IM messages14.

It can be appreciated that in this example, the ID field736can be used to specify the application ID to identify a IM application on the mobile device10. Where the IM application relates to, for example, an IM system, the message type field730can also be used to designate an IM communication, and the ID field736would then correspond to a conversation ID, i.e. a conversation thread the message12,14corresponds to (e.g. such that each message12,14is identified by the conversation in which it was sent).

Other information or attributes may be included in the IM message12,14, such as a subject field (not shown) to enable a subject for part or all of a conversation (in an IM example) to be transported with the IM message12,14(e.g. to create new subjects, modify subjects, notify others of subjects, etc.), or application details field (not shown) to provide application-specific information such as the version and capabilities of the application.

The IM system700can utilize any suitable IM protocol operated by, for example, a IM router (not shown), which may be part of the messaging infrastructure18. It can be appreciated however that a stand-alone IM configuration (i.e. that does not rely on the messaging infrastructure18—not shown) may equally apply the principles herein. The IM system700may also enable mobile devices10to communicate with desktop computers thus facilitating, for example, communications such as instant messaging (IM) between mobile applications and desktop applications on the desktop computer.

The IM system700can be implemented using a router-based communication infrastructure, such as one that provides email, SMS, voice, Internet and other communications. Particularly suitable for hosting a IM messaging router, is a wireless router or server used in systems such as those that provide push-based communication services. InFIG. 34, the messaging infrastructure18facilitates IM communications such as instant messaging between mobile devices10. IM messaging, such as IMing, is provided by an associated application stored on each mobile device10, e.g. an IM application50as shown inFIG. 8, which can be initiated, for example, by highlighting and selecting an icon from a display as is well known in the art. The IM system700routes messages between the mobile devices10according to the IM protocol being used. For example, the IM protocol may define a particular way in which to conduct IM or other types of messaging.

In general, in a IM protocol, the sender of the IM message12,14knows the source address of the intended recipient, e.g. a PIN. This may be established when the two devices request to add each other to their respective contact or buddy lists. A particular mobile device10can communicate directly with various other mobile devices10through the IM system700without requiring a dedicated server for facilitating communications. In other words, the IM system700enables the mobile devices10to communicate with each other directly over the network16in accordance with the IM protocol.

When conducting a IM session according to the example shown inFIG. 34, the mobile devices10a,10bcan communicate directly with the messaging infrastructure18in a client based exchange where, as noted above, an intermediate server is not required. A IM message12,14sent by one mobile device10is received by the messaging infrastructure18, which obtains the source address for the intended recipient (or recipients) from information associated with the message12,14(e.g. a data log) or from the message12,14itself. After obtaining the recipient's address according to the IM protocol, the messaging infrastructure18then routes the message12,14to the recipient associated with the mobile device10having such address (or recipients having respective addresses). The messaging infrastructure18typically also provides a delivery confirmation to the original sender, which may or may not be displayed to the user. The destination device can also provide such delivery information. The messaging infrastructure18may be capable of routing IM messages12,14reliably as well as being capable of holding onto the IM messages12,14until they are successfully delivered. Alternatively, if delivery cannot be made after a certain timeout period, the messaging infrastructure18may provide a response indicating a failed delivery. The messaging infrastructure18may choose to expire a message12,14if a certain waiting period lapses.

Referring toFIG. 37, to further aid in the understanding of the example mobile devices10described above, shown therein is a block diagram of an example configuration of a device configured as a “mobile device”, referred to generally as “mobile device10”. The mobile device10includes a number of components such as a main processor802that controls the overall operation of the mobile device10. Communication functions, including data and voice communications, are performed through at least one communication interface46. The communication interface46receives messages from and sends messages to a wireless network12′. In this example of the mobile device10, the communication interface46is configured in accordance with the Global System for Mobile Communication (GSM) and General Packet Radio Services (GPRS) standards, which is used worldwide. Other communication configurations that are equally applicable are the 3G and 4G networks such as Enhanced Data-rates for Global Evolution (EDGE), Universal Mobile Telecommunications System (UMTS) and High-Speed Downlink Packet Access (HSDPA), Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (Wi-Max), etc. New standards are still being defined, but it is believed that they will have similarities to the network behavior described herein, and it will also be understood by persons skilled in the art that the examples described herein are intended to use any other suitable standards that are developed in the future. The wireless link connecting the communication interface46with the wireless network12′ represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for GSM/GPRS communications.

The main processor802also interacts with additional subsystems such as a Random Access Memory (RAM)806, a flash memory808, a touch-sensitive display860, an auxiliary input/output (I/O) subsystem812, a data port814, a keyboard816(physical, virtual, or both), a speaker818, a microphone820, a GPS receiver821, a front camera817, a rear camera819, short-range communications subsystem822, and other device subsystems824. Some of the subsystems of the mobile device10perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. By way of example, the touch-sensitive display860and the keyboard816may be used for both communication-related functions, such as entering a text message for transmission over the wireless network12′, and device-resident functions such as a calculator or task list. In one example, the mobile device10can include a non-touch-sensitive display in place of, or in addition to the touch-sensitive display860. For example the touch-sensitive display860can be replaced by a display48that may not have touch-sensitive capabilities.

The mobile device10can send and receive communication signals over the wireless network12′ after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the mobile device10. To identify a subscriber, the mobile device10may use a subscriber module component or “smart card”826, such as a Subscriber Identity Module (SIM), a Removable User Identity Module (RUIM) and a Universal Subscriber Identity Module (USIM). In the example shown, a SIM/RUIM/USIM826is to be inserted into a SIM/RUIM/USIM interface828in order to communicate with a network.

The mobile device10is typically a battery-powered device and includes a battery interface832for receiving one or more rechargeable batteries830. In at least some examples, the battery830can be a smart battery with an embedded microprocessor. The battery interface832is coupled to a regulator (not shown), which assists the battery830in providing power to the mobile device10. Although current technology makes use of a battery, future technologies such as micro fuel cells may provide the power to the mobile device10.

The mobile device10also includes an operating system834and software components836to842,50and58. The operating system834and the software components836to842,50and58, that are executed by the main processor802are typically stored in a persistent store such as the flash memory808, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system834and the software components836to842,50and58, such as specific device applications, or parts thereof, may be temporarily loaded into a volatile store such as the RAM806. Other software components can also be included, as is well known to those skilled in the art.

The subset of software applications836that control basic device operations, including data and voice communication applications, may be installed on the mobile device10during its manufacture. Software applications may include a message application838, a device state module840, a Personal Information Manager (PIM)842, an IM application50, and an IM message storage58. A message application838can be any suitable software program that allows a user of the mobile device10to send and receive electronic messages, wherein messages are typically stored in the flash memory808of the mobile device10. A device state module840provides persistence, i.e. the device state module840ensures that important device data is stored in persistent memory, such as the flash memory808, so that the data is not lost when the mobile device10is turned off or loses power. A PIM842includes functionality for organizing and managing data items of interest to the user, such as, but not limited to, e-mail, contacts, calendar events, and voice mails, and may interact with the wireless network12′.

Other types of software applications or components839can also be installed on the mobile device10. These software applications839can be pre-installed applications (i.e. other than message application838) or third party applications, which are added after the manufacture of the mobile device10. Examples of third party applications include games, calculators, utilities, etc.

The additional applications839can be loaded onto the mobile device10through at least one of the wireless network16′, the auxiliary I/O subsystem812, the data port814, the short-range communications subsystem822, or any other suitable device subsystem824.

The data port814can be any suitable port that enables data communication between the mobile device10and another computing device. The data port814can be a serial or a parallel port. In some instances, the data port814can be a Universal Serial Bus (USB) port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery830of the mobile device10.

For voice communications, received signals are output to the speaker818, and signals for transmission are generated by the microphone820. Although voice or audio signal output is accomplished primarily through the speaker818, the display48can also be used to provide additional information such as the identity of a calling party, duration of a voice call, or other voice call related information.

The touch-sensitive display860may be any suitable touch-sensitive display, such as a capacitive, resistive, infrared, surface acoustic wave (SAW) touch-sensitive display, strain gauge, optical imaging, dispersive signal technology, acoustic pulse recognition, and so forth, as known in the art. In the presently described example, the touch-sensitive display860is a capacitive touch-sensitive display which includes a capacitive touch-sensitive overlay864. The overlay864may be an assembly of multiple layers in a stack which may include, for example, a substrate, a ground shield layer, a barrier layer, one or more capacitive touch sensor layers separated by a substrate or other barrier, and a cover. The capacitive touch sensor layers may be any suitable material, such as patterned indium tin oxide (ITO).

The display48of the touch-sensitive display860may include a display area in which information may be displayed, and a non-display area extending around the periphery of the display area. Information is not displayed in the non-display area, which is utilized to accommodate, for example, one or more of electronic traces or electrical connections, adhesives or other sealants, and protective coatings, around the edges of the display area.

One or more touches, also known as touch contacts or touch events, may be detected by the touch-sensitive display860. The processor802may determine attributes of the touch, including a location of a touch. Touch location data may include an area of contact or a single point of contact, such as a point at or near a center of the area of contact, known as the centroid. A signal is provided to the controller866in response to detection of a touch. A touch may be detected from any suitable object, such as a finger, thumb, appendage, or other items, for example, a stylus, pen, or other pointer, depending on the nature of the touch-sensitive display860. The location of the touch moves as the detected object moves during a touch. One or both of the controller866and the processor802may detect a touch by any suitable contact member on the touch-sensitive display860. Similarly, multiple simultaneous touches, are detected.

In some examples, an optional force sensor870or force sensors is disposed in any suitable location, for example, between the touch-sensitive display860and a back of the mobile device10to detect a force imparted by a touch on the touch-sensitive display860. The force sensor870may be a force-sensitive resistor, strain gauge, piezoelectric or piezoresistive device, pressure sensor, or other suitable device.

The steps or operations in the flow charts and diagrams described herein are just for example. There may be many variations to these steps or operations without departing from the principles discussed above. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.