Recipient blind cryptographic access control for publicly hosted message and data streams

[0001] The described embodiments generally relate to methods and apparatuses for encryption in a cloud based environment. In particular, privacy between client devices is controlled by client side processing with little or no server side processing providing a platform agnostic server.

[0002] Cloud computing is a technology that uses the internet and central remote servers to maintain data and applications to provide any number of cloud based services such as data storage, application, and computing. Cloud computing allows consumers and businesses to use applications without installation and access their personal files at any computer with internet access allowing for much more efficient computing by centralizing storage, memory, processing and bandwidth. With cloud-based services becoming increasingly popular, maintaining privacy without sacrificing system performance is more important than ever. Achieving scalability with increasingly complex server software is also challenging, and the more of the burden of privacy control that is placed on the server side, the greater the degradation of the performance of the system as a whole. Since many client devices accessing web services today have access to comparatively large amount of processing resources, it would be desirable to be able to use this client based processing resource to offload from the central servers to the individual client devices most if not all of the potentially complex computations required involved in privacy control.

[0003] Therefore, what is desired is a client side system that utilizes client device processing resources to effectuate privacy control in a cloud based environment requiring little or no server computational resources.

[0004] In one embodiment, a private communication method is described. The method can be carried out by storing at least an encrypted data portion of a private message at a server, the encrypted data portion encrypted at an authoring client device. The private message also includes information identifying a client device authorized to read the private message. At least the encrypted data portion of the private message is sent from the server to a recipient client device that performs all decryption processing required to read the encrypted data portion only if the recipient client device is authorized to read the private message in accordance with the identifying information. In this way, the server stores at least the encrypted data portion of the private message in a platform agnostic manner and without performing any encryption or decryption related processing.

[0005] In another embodiment, a multi-mode communication device is described. The communication device includes at least a communication interface arranged to send and receive information and a processor coupled with the communication interface, the processor arranged to control a secure messaging service at the communication device. The processor controls the secure messaging service by creating a first secure message that includes at least a first secure data portion encrypted with a first symmetric encryption key and first authorized recipient device information. The first authorized recipient device information includes at least a first group label bound to a first access control list that includes the first symmetric encryption key encrypted with a public key of a first authorized recipient device. The processor acts to further use the communication interface to post at least the first secure data portion to an external data storage device. A recipient device receives the first secure message and performs all decryption processing required to read the secure message only if the recipient device is authorized in accordance with the authorized recipient device information. In this way, the external data storage device stores the at least the encrypted data portion in a platform agnostic manner and without performing any encryption and decryption processing.

[0006] In yet another embodiment, a method performed by a multi-mode portable communication device having a processor and a communication interface is described. The method is carried out by creating a secure message that includes at least a secure data portion encrypted by a symmetric encryption key, and authorization information used by a recipient device to determine if the recipient device is authorized to read the secure message. At least the encrypted data portion of the secure message is posted to an external data storage device using the communication interface. The recipient device receives at least the encrypted data portion and only if authorized in accordance with the authorization information, performs substantially all decryption processing required to read the encrypted data portion. In this way, the external data storage device stores the first secure message in a platform agnostic manner and without performing any encryption and decryption processing.

[0007] In still another embodiment, non-transitory computer readable medium for storing computer code executable by a processor storing computer code executable by a processor includes computer code for storing at least an encrypted data portion of a private message at a server, the encrypted data portion encrypted at an authoring client device. The private message also including information identifying a recipient client device authorized to read the private message. The computer readable medium also includes computer code for sending at least the encrypted data portion of the private message from the server to a client device. The receiving client device performs all decryption processing required to read the encrypted data portion only if the receiving client device is authorized to read the private message in accordance with the identifying information such that the server store at least the encrypted data portion in a platform agnostic manner and without performing any encryption or decryption related processing.

[0020] In the following description, numerous specific details are set forth to provide a thorough understanding of the concepts underlying the described embodiments. It will be apparent, however, to one skilled in the art that the described embodiments may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the underlying concepts.

[0021] The examples and embodiments provided below describe a private messaging system. Operations of the private messaging system can be performed by a server. Encrypted data can be stored on the server in a platform-agnostic manner by which it is meant that the server need only deal with unstructured data without regards to specific requirements of the data being stored. Furthermore, the server operates without performing substantially any encryption/decryption processes related to the private messaging. In this way, the private messaging system offloads most of the potentially complex computation involved in privacy control from the server to the client devices such that the server requires virtually no knowledge of the data being hosted. Therefore, segregating platform-agnostic data and minimal access control burden to the server, provides for the flexibility to build highly scalable servers. Since distributed data storage is well-understood and available, delivering messages in formats that require no server processing resources for interpretation allows even basic, out-of-the-box file servers to work as powerful platforms for secure high-performance message sharing. Another advantage of the private messaging system is that the encrypted data can be stored publicly on untrusted machines for caching purposes without exposing any sensitive information.

[0022] Using the secure messaging system, the server can receive and store at least a portion of a secure message from a first client device. The secure message can include an encrypted data portion and information identifying at least a recipient client device authorized to read the secure message. In one embodiment, a second client device can receive the secure message from the server. The second client device can read the secure message only if the identifying information indicates that the second client device is authorized to read the secure message.

[0023] In one embodiment, the data portion is encrypted using a symmetric encryption key and an identity of the recipient device is embodied as a group label formed at least in part of a public key associated with the recipient device authorized to read the private message. In one embodiment, the public key can be used to encrypt the symmetric encryption key. In one embodiment, the group label can be static and be bound to an access control list that embodies a definitive list of all devices authorized to read the private message. In order to assure authenticity, the group label can be signed using a private key associated with an author of the private message and hashed to provide the group label ensuring that the group label can be reproduced by the author and no one else. The group label can be uniquely associated with the access control list, and therefore an access control list membership status can be used to determine whether or not a device is authorized to read the private message. Generally, the group label can then be created using the information regarding the devices listed in the access control list.

[0024] When attempting to read the private message, the device can quickly evaluate the group label associated with the private message to determine if the public key associated with the device is present. If the group label has been previously evaluated by the device, then an access flag status, for example, can be quickly evaluated without actually checking the content of the group label to determine if the device is authorized or not to read the private message. However, if the group label has not been previously encountered by the device, then the access control list associated with the group label can be obtained (from a message repository, for example) and queried to determine if the public key associated with the device is listed in the access control list. If the public key associated with the device is deemed to be present in the access control list, then the device is granted access to the symmetric encryption key and is authorized to read the secure message.

[0025] In one aspect of the described embodiment, the encrypted data takes the form of a data file, the data file having a header portion and a data portion (or payload) encrypted using the symmetric encryption key. The header portion includes information that aids the device in determining whether or not the recipient device is authorized to read the encrypted data portion. The header portion can include information (such as a pointer) that points to the group label. The pointer can take the form of a memory location in a memory device, such as a cache memory, where data corresponding to the group label is stored. The pointer can take the form of a URL (Universal Resource Locator) that identifies a network device (such as a server computer) for storing the data corresponding to the group label. The information in the header can also include information used to identify an access control list associated with a particular group label.

[0026] These and other embodiments are discussed below with reference to FIGS. 1-11. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes only and should not be construed as limiting.

[0027] FIG. 1 illustrates representative private messaging system 100 in accordance with the described embodiments. It should be noted that although messaging system 100 illustrates an implementation of secure messaging, the environment is merely exemplary. The features of secure messaging described herein are platform-independent such that the messaging techniques may be implemented on a variety of commercial computing platforms having a variety of processors, memory components, and various other components.

[0028] Messaging system 100 can include communication network 102 and any number of messaging devices 104. More generally speaking, messaging devices 104 can take the form of a multi-mode communication device by which it is meant that messaging device 104 can both author and send secure message in an authoring mode and receive and read secure messages in a reading mode. Communication network 102 can be implemented as any one or combination of a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and the like. Communication network 102 can include network device 106. Network device 106 can be associated with a network address. Network device 106 can include data storage devices, server computers, or any device or service consistent with a cloud computing environment. Although shown as a single communication network, communication network 102 can be implemented using any type of network topology and any network communication protocol, and can be represented or otherwise implemented as a combination of two or more networks. For example, a digital network can include various hardwired and/or wireless links, routers, gateways, and so on to facilitate communication between the communication network 102 and representative messaging devices 104.

[0029] Messaging device 104 can be implemented in any number of embodiments to include a computing device, a mobile messaging device, an appliance device, a gaming system console, an entertainment system component, a cell phone, a tablet computer, a smartphone, and as any other type of messaging device that may be implemented in a messaging system. Messaging device 104 can also represent logical clients that may include a user at messaging device 104, other devices, and/or software applications that implement embodiments of secure instant messaging. Messaging device 104(1) and messaging device 104(2) can also configured for direct communication via a peer-to-peer network by which the messaging devices can exchange real-time communications, such as instant messages. The peer-to-peer network can be implemented as a separate and independent communication link from the communication network(s) 102. Additionally, the peer-to-peer network can be implemented using any type of network topology and any network communication protocol, and can be represented or otherwise implemented as a combination of two or more networks.

[0030] Messaging device 104 can include one or more processors 108 (e.g., any of microprocessors, controllers, and the like) which process various computer executable instructions to control the operation of messaging device 104, to communicate with other electronic and computing devices, and to implement embodiments of secure messaging. Messaging devices 104 can also include messaging application 110 that is executable by processor 108. For example, messaging device 104(1) can participate in a messaging session with another messaging device, such as messaging device 104(2). The messaging session can be peer-to-peer by way of the peer-to-peer network or by way of communication network 102. Messaging application 110 provides that users at each of the respective messaging devices 104, when participating in a messaging session, can communicate with each other by way of instant text messages, multi-media exchange, voice communications, avatars (e.g., visual representations), and the like. The messages (or other communications) are exchanged via the peer-to-peer network as well as via communication network 102 in real-time. It should be noted, however, that even in real time, the messages can experience delayed delivery when the messages are logged or when a recipient messaging device is off-line or otherwise unavailable.

[0031] Messaging devices 104 can include encryption module 112 to implement embodiments of secure messaging as described further below. It should be noted that, although messaging application 110 and encryption module 112 are each shown as independent applications, messaging application 110 can be implemented to include encryption module 112 to form a multi-functional component of the messaging device 104. Further, although each of the messaging application 110 and the encryption module 112 in messaging device 104 is illustrated and described as a single application configured to implement embodiments of secure messaging, either or both of the messaging application 110 and the encryption module 112 can be implemented as several component applications distributed so each can perform one or more functions in messaging device 104 and/or in a messaging system 100.

[0032] FIG. 2 illustrates an exemplary messaging system 200 in which embodiments of secure messaging can be implemented that also includes components of messaging system 100 shown in FIG. 1. In system 200, the messaging devices 104 each include the respective messaging applications 110 and the encryption modules 112 as described above with reference to FIG. 1. Messaging application 110(1) at messaging device 104(1) includes and/or generates various communications and data 202, and similarly, the messaging application 110(2) includes and/or generates various communications and data 204. In one embodiment, data 202 can take the form of secure data 202 that can be transferred from messaging device 104(1) to communication network 102. In one embodiment, data 202 can be stored in data repository 206 associated with network device 106. Data repository 206 can provide data storage and retrieval services for messaging system 200 by storing secured and unsecured data in a platform agnostic manner. By platform agnostic, it is meant that data repository 206 does not require information related to the structure or other particulars of data 202 in order to provide the requisite storage services for messaging system 200. Data repository 206 can also be in communication with messaging device 104(2) in such a way that messaging device 104(2) can interact with data repository 206 to receive data 202 stored therein. Data 202 (and 204) can take any number of forms or be any one or combination of an instant message, a file transfer, an image transfer, a text-based communication, an audio communication, a video communication, or an audio/video communication, any of which may be communicated as an encrypted or otherwise secure communication via communication network 102.

[0033] Messaging devices 104 can include memory 208 that can store contact information 210 for each respective messaging device 104. In one embodiment, contact information 210 can include identification of a group of messaging devices (recipients) authorized to read a secure message. In one embodiment, the identities of the messaging devices authorized to read the secure message can be embodied as group label (GL) 212 uniquely bound to access control list (ACL) 214. Group label 212 can take the form a string of text (or other similar identifier) that uniquely identifies the group of authorized recipient devices listed in access control list 214. Generally, group label 212 is configured in such a way that the message author, and only the message author, can reliably and quickly reproduce group label 212. This can be accomplished in a particular embodiment by signing with the author's private key and then hashing the signature using a cryptographic hash function (such as SHA-512). In this way, group label 212 takes the form of a compact and unique identifier for the set of recipient devices that can only be reproduced by the message author in a reliable and efficient manner. Group label 212 can reside in or be associated with data repository 206 and can be accessible to both messaging device 104(1) and 104(2) via communication network 102. In an instant messaging environment, both group label 212 and access control list 214 can reside in or be associated with messaging device 104(1) and/or messaging device 104(2). In this way, secure messages 202/204 can be passed between messaging devices 104(1) and 104(2) using peer-to-peer network independent of communication network 102.

[0034] Access control list 214 is a publicly available list that list devices authorized to read a secure message. In one embodiment, access control list 214 can be created by generating a random symmetric encryption key (size such as AES 256 bits) that can be used to encrypt the message and any relevant metadata. A copy of the symmetric encryption key is encrypted with an authorized recipient device's public key using, for example, randomly padded RSA using PKCS #1, for example or OAEP to prevent collision based brute forcing. The encrypted copies of the symmetric encryption key can then be stored in a suitable list container format without being associated with any identifiable information. The group label can be stored in the same container and signed with the message author's private key for authentication purposes. In this way, access control list 214 is formed of a list of keys each being one symmetric encryption key encrypted several times over for all authorized recipient devices. It should be noted that the identity of the authorized message recipients cannot be revealed through access control list 214 but access control list 214 can nonetheless be easily reused for subsequent messages to the same group of recipients. The message author can also added to the list of authorized recipients in order to maintain access to the secure message once it has been posted.

[0035] In some instances, a double blind variation of access control list 214 can be formed by foregoing the use of a group label derived from the identities of the authorized recipients and using instead a constant arbitrary textual label (such as “Friends”). Since there is no label tied to a fixed set of recipients, the message author can rewrite the double blind access control list on the server to dynamically add new recipients. Therefore, when the double blind access control list is being used, a “clear” unpublished access control list 216 can be created listing all authorized recipient devices. In this way, even though the identity of all of the double blind access control list are unavailable even to the message author, the message author can rely on clear access control list 216 to identify all authorized recipients in the group associated with double blind access control list.

[0036] Using the double blind variation of the access control list precludes the performance benefits accrued with client side caching and reuse of access control list 214, however, the dynamic nature of the double blind access control list allows for implementation of lists where new users can join an existing group and receive all prior and future messages. However, in order to remove a member from the double blind access control list, a new double blind access control list must be regenerated with a new symmetric key and re-encrypting all issued posts to prevent access by the removed member. In yet another variation, the access control list can be generated and used only once and be associated with a randomly generated group label. In this variation, the access control list is both double-blind and low performance but can be useful in those situations where traffic analysis is a recognized security threat.

[0037] Only those messaging devices listed as a member in access control list 214, and therefore considered to be authorized, can decrypt secure message 202. In one embodiment, once a messaging device has determined that it is a member of a particular access control list, the messaging device can flag the group label associated with the particular access control list with, for example, an accept flag. In this way, the accept flag alone can be used as a marker to indicate that the secure message associated with the flagged group label can be read by the messaging device thereby greatly saving both time and computational resources. On the other hand, once the messaging device has determined that is it not a member of the particular access control list, then the group label associated with the access control list can be appropriately flagged as, for example, not accept. In this way, messaging devices can easily determine whether to skip over and not even attempt to decrypt messages based solely a group label flag status. For example, if a group label flag status associated with a secure message indicates that a particular messaging device is not an authorized recipient messaging device with respect to the secure message, then no further processing by the messaging device is needed.

[0038] However, in those cases where a particular group label is not flagged (indicating that the messaging device has not yet evaluated the group label) the messaging device can query the access control list associated with the group label. The query can ascertain access control list membership status of the messaging device by determining if the messaging device is or is not a member of the access control list and as a result the group label flag can be set appropriately. It should be noted that an advantage of messaging system 200 includes the fact that the same symmetric encryption key can be re-used for messages sent to the same groups) of recipients. In other words, for a given set of recipients A that is equal to a set of recipients B, the group labels for recipients A and B will be cryptographically equal since the group labels are sorted hashes. Using the same symmetric encryption key for all messages bound for the same set of recipients allows for efficient caching and fast message decryption.

[0039] In another embodiment, a portable data storage device can be used to support private messaging. For example, FIG. 3 shows representative portable storage device 300 in the form of, for example, a FLASH memory in the form of what is commonly referred to as a “thumb drive”. In this arrangement, portable storage device 300 can interface with messaging device 104(1) in any suitable manner to retrieve and store secure message 302 that can include group label 304, and associated access control list 306 and encrypted data 308. In this way, secure message 302 can be physically transported in a safe and secure manner in such a way that only those messaging devices that can read group label 304 or is a member of access control list 306 can decrypt data 308 to read secure message 302. This embodiment is particularly well suited for those situations where a secure message is made physically available to a number of individuals but where only those designated as recipients can read the secure message, not all of whom are allowed to read secure message 302.

[0040] Referring back to FIG. 2, messaging device 104(1) can author secure message 202 in a message authoring operation using messaging application 110(1), encryption module 112(1) and, optionally, data stored in memory 208(1). Secure message 202 can be authored by receiving (unsecured/clear) data 218 from memory 208(1). Data 218 can be, for example, a message intended for a specific (group of) recipient message device 104(2). Data 218 can include video data, text data, audio data and so forth. Data 218 can be encrypted using encryption module 112(1). Encryption module 112(1) can encrypt data 218 using any number of available and well known encryption protocols such as symmetric encryption key encryption, public-private key encryption, and so on. In this example, encryption module 112(1) can use symmetric encryption key 220 to generate encrypted data 222. In order to author a secure message, a group of messaging devices is identified to receive the secure message. If the group is an established group known to the author, then the group label associated with the group is identified and a symmetric encryption key used to encrypt the secure message is obtained. The symmetric encryption key can then be used to generate encrypted data 222. However, if no group label is available (if a new group of recipient devices for example), and then a new access control list is generated for the group and bound to a group label that uniquely identifies the recipient devices.

[0041] In one embodiment, messaging device 104(1) can post secure message 202 as encrypted data 222 only to data repository 206 separate from group label 212. In another embodiment, messaging device 104(1) can post secure message 202 by inserting encrypted data 222 and group label 212 into a container that is then forwarded to data repository 206. In any case, messaging device 104(2) can query group label 212 to quickly determine those messages (if any) stored in data repository 206 for which messaging device 104(2) is authorized recipient device and skip over those messages that messaging device 104(2) is not an authorized recipient.

[0042] In another embodiment, a lightweight implementation of private messaging system 200 can include group label 212 residing in or being associated with network device 106 separate from data received from messaging device 104(1). For example, group label 212 can reside in communication network 102 separate from but otherwise associated with secure message 202. For example, secure message 202 can take the form of a data file along the lines shown in FIG. 3 having a header portion and payload, or data, portion. The data portion of data file can be encrypted while the header portion can remain open. In this scenario, the encrypted data portion can be stored in a storage device separate from header portion since the header portion can include group label 212 or an indication (such as a pointer) of a location where group label 212 is stored. Group label 212 can also provide an indication of a location where symmetric encryption key 220 is stored in those situations where messaging device 104(2) is able to read group label 212. For example, the header portion can include a network identifier (such as a Universal Resource Locator, or URL) identifying a network device on which group label 212 resides.

[0043] FIG. 4 illustrates messaging system 200 in which messaging device 104(2) is performing a read operation in accordance with the described embodiments. Initially, messaging device 104(2) can determine if secure message 202 is available to read by, for example, evaluating status flag 224 posted by data depository 206 (or network 102) indicating the presence of secured message 202. Once messaging device 104(2) has determined that secure message 202 is present in data depository 206, a determination can be made if messaging device 104(2) is a recipient device able to read secure message 202. In one embodiment, the determination can be made by evaluating group label 212 associated with secure message 202. Messaging device 104(2) can evaluate group label 212 by checking cache 226 of group labels previously seen by messaging device 104(2). It should be noted that cache 226 can reside in network 102. In some cases, cache 226 can reside in messaging device 104(2) thereby reducing signals between messaging device 104(2) and network 102 and overall network traffic. This reduction in network traffic can be advantageous to the performance of private messaging system 200 during times of reduced available bandwidth.

[0044] If group label 212 is stored in cache 226, then messaging device 104(2) can determine if it is an authorized recipient device using the previous evaluation of group label 212 by messaging device 104(2). For example, if the previous evaluation indicates that messaging device 104(2) is an authorized recipient device, (i.e., is a member of the access control list 214) then messaging device 104(2) can access symmetric encryption key 220 associated with group label 212. Symmetric encryption key 220 can, in turn, be used to decrypt and read secure message 202. If group label 212 associated with secure message 202 is not included in cache 226, then messaging device 104(2) can query access control list 214 (which can be located local to messaging device 104(2) or in network 102) associated with group label 212 to determine whether or not messaging device 104(2) is a member of access control list 214. If it is determined that messaging device 104(2) is a member of access control list 214, messaging device 104(2) can be granted access to use symmetric encryption key 220 in order to read secure message 202. Symmetric encryption key 220 used to decrypt secure message 202 can be obtained in any number of ways. For example, symmetric encryption key 220 can be stored in symmetric encryption key repository 228 located in any number of appropriate locations accessible by messaging device 104(2). In one scenario, symmetric encryption key repository 228 can be associated with network device 106 or be local to messaging device 104(2) in which case messaging device 104(2) can obtain symmetric encryption key 220 directly from the symmetric encryption key repository 228 without accessing network 102.

[0045] There are a number of techniques that messaging device 104(2) can use to quickly check the contents of cache 226 for its membership status in access control list 214. In one embodiment, a flag status associated with group label 212 associated with secure message 202 can be used to quickly provide messaging device 104(2) with the requisite information. For example, group label 212 can have a flag status set to a first flag status indicating the messaging device 104(2) is a member of access control list 214 and is therefore a recipient device and has access to symmetric encryption key 220. Symmetric encryption key 220 can then be used to decrypt encrypted data 222 in secure message 202 by encryption module 112(2). On the other hand, a second flag status can indicate that messaging device 104(2) in not a member of access control list 214 and is not a recipient device and therefore does not have access to symmetric encryption key 220. As a result messaging device 104(2) is not granted access to symmetric encryption key 220 and therefore cannot read secure message 202 and it can be skipped.

[0046] In another scenario if cache 226 is either not available or group label 212 is not stored therein, then messaging device 104(2) can obtain symmetric encryption key 220 from access control list 214 directly. In this scenario, messaging device 104(2) can locate an entry (if any) associated with messaging device 104(2) in access control list 214 using any number of search algorithms. It should be noted that for access control lists having a large number of members, searching for a key in the access control list can be optimized by sorting the keys when the access control list is generated using standard hash table techniques to provide a best guess index. Messaging device 104(2) can decrypt entries within access control list 214 to determine if messaging device 104(2) has access to the symmetric encryption key used to decrypt the secure message 102. If the decryption is successful, then the symmetric encryption key corresponding to the location in the access control list can be stored in a cache memory, such as symmetric encryption key repository 228, for example. If, however, the decryption fails for all keys in the access control list, then the access control list can be flagged as no access for messaging device 104(2) for secure message 202. In any case, once messaging device 104(2) is granted access and acquires symmetric encryption key 220, encryption module 112(2) can use symmetric encryption key 220 to decrypt encrypted data 222 thereby allowing messaging device 104(2) to read secure message 202.

[0047] From a strictly server side viewpoint, network device 106 acts only as a data store and does not provide any computer resources for encryption or decryption of secure message 202. In this regard, storage services provided by network device 106 can be platform agnostic in that the knowledge of the particular form or format of the data is not required for network device 106 to provide the requisite storage services. For example, in the context of private messaging system 100, network device 106 simply receives secure message 202 from messaging device 104(1). Network device 106 then stores relevant portions of secure message 202 until such time as required by messaging device 104(2) to forward at least an encrypted portion of secure message 202. In some cases, network device 102 can provide in addition to a data storage service, a stored secured message notification service that provides notification to an interested messaging device that secured data (such as secure message 202) has been posted to network device 106. For example, when messaging device 104(1) forwards secure message 202 to data repository 206, communication network 102 can post flag 224 described above.

[0048] FIG. 5 shows a representative flowchart detailing process 500 for client device authoring a secure message in accordance with the described embodiments. It should be noted that process 500 is a process that can be considered a client side process by which it is meant that process 500 is performed using only client device computing resources. For example, if the client device is a portable communication device such as an iPhone smartphone manufactured by Apple, Inc. of Cupertino, Calif. then substantially all processes related to encrypting and decrypting the secure message can be executed entirely on the smartphone platform. In this way, network traffic related to encryption processes can be kept to a minimum.

[0049] Accordingly, process 500 can begin at 502 by a client device determining if information relating to an identity of a recipient device is available. It should be noted that although it is understood that an individual user is likely (but not the only possibility) the entity driving the private communication, the identity information points to the client device and not an individual. That having been said, the identity information can be embodied as a group label. If it is determined that the group label is available indicating those client devices authorized to read the secure message, then the authoring client device is granted access to a symmetric encryption key associated with the group label at 504. The symmetric encryption key can be used by the authoring client device to encrypt a data portion (also referred to as a message body) at 506. The encrypted message is then published at 508 to a network and made available to any client device that is a member of the network but can only be read by those network members identified in the group list. In one embodiment, the group label is combined with the encrypted message body to form the secure message. This configuration is well suited for applications whereby the secure message is physically transported using a portable data storage device such as a non-volatile memory based thumb drive in which case the encrypted message and the group label identifying the authorized recipients are maintained in a single container. Returning to 502, if on the other hand, it is determined that the group label is not available, then a determination is made at 510 if an access control list for the group of recipient devices is available. If the access control list is not available, then the access control list is generated at 512 and a group label is generated at 514 and associated with the access control list at 516 and control is passed to 504. If on the other hand at 510, the access control list is available, then control is passed directly to 514 where the group label is generated and associated with the access control list at 516.

[0050] FIG. 6 shows a flowchart detailing process 600 for generating a group label. In particular process 600 can be a particular implementation of operation 510 shown in FIG. 5 and described above. In one embodiment, process 600 can begin at 602 by obtaining public keys associated with all recipient devices authorized to read the private message. At 604, the public keys obtained at 602 are sorted and concatenated at 606. At 608, the list of concatenated public keys is signed with a private key associated with an author of the message and a hash operation is performed on the signature at 610. In this way, only the author of the message has the ability to alter the content of the group label by adding or removing listed members of the group label.

[0051] FIG. 7 shows a representative flowchart detailing process 700 for reading a secure message in accordance with the described embodiments. Process 700 can be carried out by any client device in communication with a storage device in which a secure message is posted. In those situations where the private message system utilizes a non-server computing environment, such as a peer-to-peer network, then the secure message can be posted at a first (sending) client device in communication directly with at least a second (receiving) client device. However, only for sake of simplicity, a server type communication network is presumed. Accordingly, at 702, a determination is made by at least one client device, other than the authoring client device, that a secure message is posted. The determination can be carried out in any number of different ways. For example, a storage device at which the secure message is stored can post a flag or other such signal indicating that the secure message has been posted and is stored therein. In other embodiments, the authoring client device can post a signal indicating that the secure message has been posted and all interested client devices other than the authoring client device can attempt to read the secure message stored at a location indicated by the authoring client device.

[0052] In any case, once it has been determined that the secure message has been posted, then at 704 a determination is made if a client device is authorized to read the posted secure message. Authorization can be determined using the group label associated with the secure message. For example, if the client device has previously encountered the group label, then the client device will know (as long as the client device is still authorized) based upon the previous encounter whether or not it is a member of the group allowed to read the secure message. However, in some instances the group label may not be available in which case; the client device can query the access control list associated with the secure message to determine the authorization status of the client device. For example, if a public key associated with the client device is embodied in the access control list, then the client device is authorized to read the secure message. If the client device determines that it is not authorized to read the secure message and if at 706 it is determined that there are no other secure messages, then process 700 can end. If on the other hand it is determined at 706 that there are additional secure messages, then control is passed back to 704.

[0053] Returning back to 704, if it has been determined that the client device is authorized to read the secure message, then at 708, the secure message is received at the client device and the secure message is read at 710. In one embodiment, the client device can use a data key (such as a symmetric encryption key) to unlock the secure message. For example, if the a message is encrypted using a symmetric encryption key, then the secure message can be read using the symmetric encryption key obtained from the access control list or a cache of symmetric encryption keys made available to authorized client devices.

[0054] FIG. 8 shows a flowchart detailing process 800 for querying an access control list associated with a secure message to determine if the client device is authorized to read the secure message. Process 800 can be carried out by initially obtaining a list of keys from the access control list at 802. Each of the lists of keys can be associated with a particular client device and as such can indicate if the client device is authorized to read the secure message. At 804, an attempt is made to decrypt one of the keys and if determined at 806 to be successful, then a symmetric encryption key associated with the access control list is obtained at 808 and cached at 810. In one embodiment, the symmetric encryption key can be cached in symmetric encryption key repository made available to all messaging devices that have been listed in the access control list. Once the symmetric encryption key has been obtained, the access control list is flagged as being accessible at 812.

[0055] Returning to 806, if the decryption is determined to be not successful and if it is further determined at 814 that there are no additional keys, and then a not accessible flag is associated with the access control list at 816 and process 800 ends. If, however, it is determined at 814 that there are additional keys, then a next key in the list is obtained at 818 and control is passed back to 804 for additional processing.

[0056] FIG. 9 shows a representative flowchart detailing process 900 for generating an access control list as one implementation of step 512 shown in FIG. 5 in accordance with the described embodiments. Process 900 can begin at 902 by obtaining a list of recipient public keys and an authoring private key that in one embodiment can be embodied as a group label. The group label being a compact and unique identifier for a set of message recipients authorized to read the secure message that can only be reproduced by the message author. At 904, obtain a public key for each of the message recipients listed in the group label. At 906, a symmetric encryption key sized in accordance with, for example, AES 256 bits is obtained. At 908, a copy of the symmetric encryption key is encrypted for each of the public keys listed in the group label. In one embodiment, the message author is also added to the access control list to maintain the ability of the message author reading the secure message once it is posted. At 910, the encrypted copies of the symmetric encryption key are sorted and stored in a container format without any identifiable information. In one embodiment, the group label is stored in the container along with the access control list and the access control list is signed with the message author's private key to assure authenticity.

[0057] FIG. 10 shows a flowchart detailing a server side private messaging process 1000 in accordance with the described embodiments. Process 1000 can begin at 1002 by receiving a secure message at a server from a first client device. The secure message can include recipient information identifying all client devices authorized to read the secure message. The secure message can also include an encrypted data portion encrypted using a symmetric encryption key such that only those client devices granted access to the symmetric encryption key can decrypt and read the secure message.

[0058] At 1004, the secure message is stored at the server in a platform agnostic manner by which it is meant that the storage services provided by the server need only deal with unstructured data without regards to specific requirements of the data being stored. In one embodiment, the server can provide a notification that the secure message has been received and is available for interested client devices. At 1006, the server can provide access of the secure message and the identifying information to a second client device. The second client device can read the secure message only if the identifying information indicates that the second client device is authorized to read the secure message. In this way, the server is not required to use any server computer processing resources for encryption or decryption purposes and is only required to provide straightforward data storage services.

[0059] FIG. 11 illustrates various components of an exemplary computing and/or messaging device 1100 in which embodiments of secure instant messaging can be implemented. Further, the computing and/or messaging device 600 can be implemented as any one or more of the messaging devices 104 described with reference to FIGS. 1-4. Computing and/or messaging device 1100 includes one or more media content inputs 1102 which may include Internet Protocol (IP) inputs over which streams of media content are received via an IP-based network, an intranet, or the Internet. Device 1100 further includes communication interface(s) 1104 which can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. A wireless interface enables device 1100 to receive control input commands and other information from an input device, such as from remote control device, PDA (personal digital assistant), cellular phone, or from another infrared (IR), 802.11, Bluetooth, or similar RF input device.

[0060] A network interface provides a connection between the computing and/or messaging device 1100 and a communication network (e.g., communication networks 102 or peer-to-peer network) by which other electronic, computing, and messaging devices can communicate data with device 1100. Similarly, a serial and/or parallel interface provides for data communication directly between device 1100 and the other electronic, computing, and/or messaging devices. Computing and/or messaging device 1100 also includes one or more processors 1108 (e.g., any of microprocessors, controllers, and the like) which process various computer executable instructions to control the operation of device 1100, to communicate with other electronic and computing devices, and to implement embodiments of secure instant messaging. Device 1100 can be implemented with computer readable media 1110, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device can include any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), a DVD, a DVD+RW, solid state memory, and the like.

[0061] Computer readable media 1110 provides data storage mechanisms to store various information and/or data such as software applications and any other types of information and data related to operational aspects of the computing and/or messaging device 1100. For example, an operating system 1112 and/or other application programs 1114 can be maintained as software applications with the computer readable media 1110 and executed on processor(s) 1108 to implement embodiments of secure instant messaging. For example, when implemented as a messaging device computer readable media 1110 maintains a messaging application 110 and an encryption module 112 to implement embodiments of secure instant messaging.

[0062] The computing and/or messaging device 1100 also includes an audio and/or video output 1116 that provides audio and video to an audio rendering and/or display system that may be external or integrated with device 1100, or to other devices that process, display, and/or otherwise render audio, video, and display data. Although not shown, a user can interface with the device 1100 via any number of different input devices such as a keyboard and pointing device (e.g., a “mouse”). Other input devices may include a microphone, joystick, game pad, controller, serial port, scanner, touch sensitive device and/or any other type of input device that facilitates instant messaging.

[0063] Various aspects of the described embodiments can be implemented by software, hardware or a combination of hardware and software. The described embodiments can also be encoded as computer program code on a non-transitory computer readable medium. The non-transitory computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of the non-transitory computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape and optical data storage devices. The computer program code can also be distributed over network-coupled computer systems so that the computer program code is stored and executed in a distributed fashion.

[0064] The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of the specific embodiments described herein are presented for purposes of illustration and description. They are not targeted to be exhaustive or to limit the embodiments to the precise forms disclosed. It will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.

[0065] The advantages of the embodiments described are numerous. Different aspects, embodiments or implementations can yield one or more of the following advantages. Many features and advantages of the present embodiments are apparent from the written description and, thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, the embodiments should not be limited to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents can be resorted to as falling within the scope of the invention.