US9584316B1 - Digital security bubble - Google Patents

Abstract

A digital security bubble encapsulation is disclosed. A first key and a device identifier of at least one recipient is requested from a first server. A message containing one or more components is encrypted using a second key. The second key is encrypted using the first key. The encrypted message, the encrypted second key, and the device identifier are encapsulated in a digital security bubble encapsulation. The digital security bubble encapsulation is transmitted to a second server.

Description

CROSS REFERENCE TO OTHER APPLICATIONS

This application is a continuation of co-pending U.S. patent application Ser. No. 14/089,634, entitled DIGITAL SECURITY BUBBLE filed Nov. 25, 2013, which is incorporated herein by reference for all purposes, which is a continuation of U.S. patent application Ser. No. 13/942,554 entitled DIGITAL SECURITY BUBBLE filed Jul. 15, 2013, now U.S. Pat. No. 8,625,805, which claims priority to U.S. Provisional Patent Application No. 61/672,099 entitled DIGITAL SECURITY BUBBLE IS A CROSS PLATFORM ALGORITHM THAT SECURES COMMUNICATIONS ORIGINATING FROM A MOBILE DEVICE, COMPUTER, WEB, OR ANY OTHER DEVICE CONNECTED VIA EITHER A CELLULAR NETWORK, WIFI, BLUETOOTH, OR OPTICAL CONNECTION WITH OTHER DEVICES. COMMUNICATIONS COULD BE TEXT, VIDEO, AUDIO, PICTURES, AND ANY TYPE OF FILES THAT COULD BE SENT AS ATTACHMENTS filed Jul. 16, 2012 and is incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

Users of electronic devices increasingly desire to communicate privately and securely with one another. Unfortunately, existing approaches to securing communications can be difficult and/or cumbersome to use. As one example, some approaches to data security make use of digital certificates or keys, or pre-shared passwords, which can be tedious to manage. Further, existing approaches are often susceptible to interception (e.g., eavesdropping and man-in-the middle attacks), forensic analysis, and impersonation.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.

FIG. 1 illustrates an embodiment of an environment in which the exchange of secure communications is facilitated by a security platform.

FIG. 2 illustrates an embodiment of an installation and registration process.

FIG. 3 illustrates an example of an interface.

FIG. 4 illustrates an example of a message sending process.

FIG. 5 illustrates an example of a digital security bubble.

FIG. 6 illustrates an example of a digital security bubble.

FIG. 7 illustrates an example of a portion of a digital security bubble.

FIG. 8 illustrates an example of a portion of a digital security bubble.

FIG. 9 illustrates an example of a portion of a digital security bubble.

FIG. 10 illustrates an example of a process for accessing a message included inside a digital security bubble.

FIG. 11 illustrates an example of an interface.

FIG. 12 illustrates an example of a process for mitigating screen capture attempts.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

FIG. 1 illustrates an embodiment of an environment in which the exchange of secure communications is facilitated by a security platform (e.g., security platform102). In the environment shown inFIG. 1, a “digital security bubble” (DSB), described in more detail below, encapsulates or is otherwise provided around a message. The DSB allows information such as encryption information, hardware binding information, message security controls, and decryption information—for multiple recipients—to securely travel with the message. Further, the DSB provides cross-platform support. For example, techniques described herein can be deployed on a variety of operating systems (e.g., Linux, iOS, and Windows), on a variety of smart phone platforms (e.g., iPhone, Android, Windows, Blackberry, etc.), and on a variety of device types (e.g., mobile smart phones, tablets, laptops, desktops, etc.). Using techniques described herein, only intended accounts on intended devices are able to decrypt the messages. Thus, for example, the security platform is unable to decrypt messages.

Users of client devices, such as client devices106-114 communicate securely with one another using techniques described herein. As shown inFIG. 1, client devices include personal computers (110), laptop computers (108), tablets (106), and mobile telephony devices (112,114). Some client devices, e.g.,tablet device106, make use of techniques described herein via a messaging application (also referred to as an “app”) obtained from asoftware distribution server106. Examples of software distribution servers (which can comprise a single server or multiple servers working in cooperation) include app stores (e.g., provided by Apple, Google, Blackberry, Microsoft, and Blackberry) and other webservers offering app downloads. Client devices can also make use of a web interface (e.g., provided by platform102) instead of or in addition to a dedicated messaging application. Other types of devices not depicted inFIG. 1 can also be used in conjunction with the techniques describe herein, such as game consoles, video players (e.g., incorporating DVD, Blu-ray, Red Laser, Optical, and/or streaming technologies) and other network-connected appliances, as applicable.

Communications are exchanged via one or more networks (depicted collectively inFIG. 1 as network cloud104). Such networks can include wired, wireless, cellular, and satellite networks. And, such networks can be closed/private networks, as well open networks (e.g., the Internet). Further, as used herein, “communications” and “messages” can take a variety of forms, including: text messages, documents, audiovisual files, SMSes, voice and video calls. Further, the content can pertain to electronic transactions such as credit card security, password protection, directories, and storage drive protection, video on demand security, online gaming, gambling, electronic distribution of music, videos, documents, online learning systems, databases, cloud storage and cloud environments, bank transactions, voting processes, military communications, security of medical records, communication between medically implanted devices and doctors, etc. As will be described in more detail below, the exchange of communications is facilitated bysecurity platform102.

A. Installation/Initialization/Registration

Suppose a user of client device106 (hereinafter referred to as “Alice”) would like to send a secure message to her friend, Bob (a user of client device114) in accordance with techniques described herein. In some embodiments, in order to send a message Bob, Alice first obtains a copy of a messaging application suitable for her device. For example, if Alice's tablet device runs iOS, she could obtain an “app” for her tablet from the Apple App Store (an example of software distribution server106). Bob similarly obtains an appropriate application suitable for his client device114 (e.g., an Android-based smartphone) from an appropriate location (e.g., the Google Play store). In some embodiments, client devices make use of a web-based application (e.g., made available byplatform102 through interface118), instead of, or in addition to, a dedicated installed application.

Once Alice'stablet106 has obtained a copy of the messaging app, the app is installed, and Alice is able to register for an account. An instance of a messaging app usable in conjunction with the techniques described herein is depicted inFIG. 1 as app116 (installed on device106). Examples of events that can occur during an installation/initialization/registration process (200) are illustrated inFIG. 2 and will now be described.

In some embodiments,process200 is performed on a client device, such as Alice'sclient device106. The process begins at202 when a public/private keypair for the application is generated, on client device106 (e.g., using RSA, ECDH, or any other asymmetric encryption algorithms). As one example, the keypair can be generated using Eliptic Curve Algorithm with Diffie Helman Key Exchange (ECDH). Other cryptographic standards can also be used, such as RSA. At204, a “random server seed” is generated, and at206, a “random local seed” is generated. The seeds are used in conjunction with cryptographic key generation, and in some embodiments, the seeds are determined based on captured hardware information (described in more detail below).

At208, a device identifier (“deviceID”) is created from captured hardware information. Examples of captured hardware information include: hard drive identifiers, motherboard identifiers, CPU identifiers, and MAC addresses for wireless, LAN, Bluetooth, and optical cards. Combinations of information pertaining to device characteristics, such as RAM, CACHE, controller cards, etc., can also be used to uniquely identify the device. Some, or all, of the captured hardware information is run through a cryptographic hash algorithm such as SHA-256, to create a unique deviceID for the device. The captured hardware information can also be used for other purposes, such as to seed cryptographic functions.

At210, Alice is asked, via an interface provided byapp116, to supply a desired username. Alice enters “Alice” into the interface. A determination is made as to whether the username is available. As one example,app116 can supply a cryptographic hash of “Alice” toplatform102 for checking. Ifplatform102 does not already have a record for that hash, the username “Alice” is available for Alice to use. Ifplatform102 already has a record of that hash, Alice is instructed by the interface to pick an alternate username. Once Alice has selected an available username, she is asked to supply a password.

At212, an application identifier (“appID”) is created. The appID is a unique identifier for the particular installation of the messaging app. If Alice installs the messaging app on multiple devices, each of her devices will have its own unique appID. (And, each of her devices will also have its own unique deviceID.) In some embodiments, the appID is created by hashing Alice's selected password and other information such as device information.

Finally, at214 Alice's public key, deviceID, and appID are sent toplatform102 in a secure manner. As one example, in someembodiments app116 is configured to communicate withplatform102 via TLS. At the conclusion ofprocess200, Alice is ready to send and receive secure communications, described in Sections C and E below, respectively.

B. Security Platform

As mentioned above,security platform102 is configured to facilitate the exchange of communications (e.g., among any/all of client devices106-114). Additional detail regarding various aspects ofplatform102 will now be provided.

Security platform102 includes one or more interface(s)118 for communicating with client devices, such as client devices106-114. As one example,platform102 provides an application programming interface (API) configured to communicate with apps installed on client devices, such asapp116 andapp138.Platform102 can also provide other types of interfaces, such as a web interface, or stand alone software programs for desktops and laptops, running on various Operating Systems (OS). The web interface can allow users of client devices such asclient devices108 and110 to exchange messages securely (whether with one another or other users), without the need for a separately installed messaging application. The stand alone software program allows users to exchange secure messages via software that is downloaded by each user.

Security platform also includes adatabase120. Included indatabase120 is a record for each user ofplatform102. Each record has associated with it information such as the user's public key, deviceID(s), appID(s), and messages. As shown inFIG. 1,database120 is relational and stores information in a variety of tables, including a table of hashed usernames (124), a table of public keys (126), a table of deviceIDs (128), a table of appIDs (130), and a table of messages (132). Other techniques can also be used to store the information used byplatform102. For example, messages can be stored in aseparate storage136 instead of being stored withindatabase120.

Finally,security platform102 includes aprocessing engine134 which performs a variety of tasks, including interacting withdatabase120 on behalf of interface(s)118. The embodiment ofplatform102 depicted inFIG. 1 comprises standard commercially available server hardware (e.g., having a multi-core processor(s), 8 G+ of RAM, gigabit network interface adaptor(s), and hard drive(s)) running a typical server-class operating system (e.g., Linux). In various embodiments,platform102 is implemented across a scalable infrastructure comprising multiple such servers, solid state drives, and/or other applicable high-performance hardware.

Wheneverplatform102 is described as performing a task, either a single component or a subset of components or all components ofplatform102 may cooperate to perform the task. Similarly, whenever a component ofplatform102 is described as performing a task, a subcomponent may perform the task and/or the component may perform the task in conjunction with other components.

C. Sending DSB Secured Messages

Returning back to Alice's desire to send a message to Bob: at the conclusion of Section A above, Alice has successfully registered her username (“Alice”) withsecurity platform102. And, Bob is also a user ofplatform102. Suppose Alice would like to send a message to Bob. She loadsapp116 and is presented with an interface that includes a “compose” option. Alice selects the compose option and is presented with a message composition interface.

An example message composition interface is shown inFIG. 3. In particular,FIG. 3 depictsinterface300 as rendered on anexample tablet device106, connected to the Internet via an appropriate connection, such as: 3G, 4G or higher cellular connection, WiFi, Satellite, wireless or wired LANs, Bluetooth, etc.Tablet device106 includes a touchscreen. An on-screen keyboard is provided for Alice inregion306. Alice can enter the usernames of one or more recipients inregion302. She can enter message text inregion304. Alice can optionally add attachments by interacting with buttons shown inregion308. Examples of attachments include, but are not limited to: documents, pictures, and audiovisual clips. By selectingbutton310, Alice can specify various message control options, such as: the lifetime/expiration of the message; on which device(s) it can be unencrypted/read; and sharing, saving, forwarding, recalling, and deleting options.

If Alice is satisfied with her message, she can send it to Bob by clicking the send button (314). If she wishes to cancel out of composing the message, she can click the cancel button (312). Suppose Alice clicks send button (314) after composing the message shown ininterface300. An example of the events that occur, in some embodiments, in conjunction with Alice sending a message is illustrated asprocess400 inFIG. 4 and will now be described.

FIG. 4 illustrates an example of a process for sending a DSB-secured message. In some embodiments,process400 is performed on a client device, such as Alice'sclient device106. The process begins at402 when the public key, deviceID, and appID of a recipient are obtained fromplatform102. As will be explained in more detail below, the recipient's public key, deviceID and appID are used in the encryption of the symmetric key used to encrypt data, and in the DSB encapsulation of the message for the hardware/appID binding of the message. As one example,app116 can request the information fromplatform102 via an API (e.g., interface118). In some embodiments, the information is retrieved when Alice enters the recipient's name intoregion302. In other embodiments, the information is retrieved when Alice clicks sendbutton314, or at any other appropriate time (e.g., while she is composing a message). In the example shown inFIG. 3, Alice is only sending a message to Bob. If she also desires to send the message to other recipients, she can enter their names inregion302 as well, and their respective public keys, deviceIDs, and appIDs will also be retrieved at402.

At404, a random symmetric encryption key is generated (e.g., byapp116 on device106). As one example, the symmetric key is an AES 256 bit key. At406, the symmetric encryption key is used to encrypt the message body, any attachments, and any message control options. In some embodiments, Alice's own information (e.g., her public key, deviceID(s), and appID(s) are included in the DSB as well. Finally, at408, the symmetric key is encrypted with the public key of each recipient. A DSB encapsulation is then generated, and contains the aforementioned components. Examples of the DSB format are provided in Section D below.

In some cases, a user may own multiple devices. For example, Bob may be the owner ofdevice114 and112, both of which are configured with secure messaging apps. Each of Bob's installations will have its own deviceID and appID. When the DSB is created, each of Bob's devices will be considered a separate device under the same username account.

The generated DSB is securely transmitted to platform102 (e.g., by being encrypted with a symmetric key shared by the app andplatform102, and also encapsulated by TLS as an additional security layer). Irrespective of how many recipients Alice designates for her message (and, e.g., how many recipients there are or how many devices Bob has), only one DSB will be created and transmitted toplatform102. Upon receipt of the DSB,processing engine134 opens the DSB and determines the recipients of the message. Specifically, theprocessing engine134 performs a match against the deviceIDs (in a cryptographic hash and camouflaged representation) included in the DSB and the deviceIDs stored indatabase120 as well as the username (in a cryptographic hash and camouflaged representation) in the DSB and the ones stored in thedatabase120. A cryptographic hash and camouflaged representation means that the hash algorithm (i.e. SHA256) that is used for the deviceID, username, and appID values, is further camouflaged, in some embodiments, by taking multiple hashes of the result values (i.e. multiple rounds of SHA256 of the previous SHA256 value—i.e. SHA(SHA(SHA(SHA . . . ))).Processing engine134 also creates an entry for the received DSB in message table132 and notifies the recipient(s) that a new message is available. In various embodiments, other actions are also performed byplatform102 with respect to the DSB. As one example,platform102 can be configured to remove the DSB as soon as the recipient successfully downloads it. As another example,platform102 can enforce an expiration time (e.g., seven days) by which, if the DSB has not been accessed by the recipient, the DSB is deleted. Where multiple recipients are included in a DSB,platform102 can be configured to keep track of which recipients have downloaded a copy of the DSB, and remove it once all recipients have successfully downloaded it (or an expiration event has occurred).

D. DSB Examples

FIG. 5 illustrates an example of a digital security bubble (DSB).DSB500 is an example of output that can be generated byapp116 as a result of executingprocess400. In the example shown,DSB500 includes a message and optional attachments (502), and one or more message controls (504) encrypted with a key Ek_1,1(encrypted portion506). In some embodiments, key Ek_1,1is generated byapp116 atportion404 ofprocess400. Additionaldetail regarding portion506 is shown inFIG. 7, where SSK inFIG. 7 is Ek_1,1ofFIG. 5 and represents the sender's symmetric shared key used to encrypt the message and attachments.

DSB500 also includes, for eachmessage recipient 1−n, the key Ek_1,1encrypted by each of the recipient's respective public keys (as shown in region508). Further,DSB500 includes a combination of each recipient's respective deviceID, hashed username, and appID (collectively denoted HWk_1-n) inregion510. These constituent parts are also referred to herein as “parameters.” Additional detail regarding the parameters is shown inFIG. 9—namely, a plurality of parameters (such as hashed username, deviceID, and appID) are encrypted using SK2, which is a symmetric key generated by the client and shared withplatform102.

In some embodiments (e.g., as is shown inFIG. 5), a spreading function is used to spread the encrypted symmetric keys inside the DSB (as shown in region512), by spreading the bits of the encrypted key in a spreading function generated pattern, with the default function being a sequential block or data. The spreading function also contains the cryptographic hashed representation of the recipient usernames that are used by the server to identify the recipients of the message and to set the message waiting flag for each of them. Finally, the DSB is itself encrypted using key Ek_1,2(encrypted portion514), which is a symmetric key shared betweenapp116 andplatform102. Additionaldetail regarding portions514 and508 are shown inFIG. 8, where SK1 inFIG. 8 is Ek_1,2inFIG. 5 and represents the symmetric encryption key shared by the app andplatform102, and where User₁Pubkey inFIG. 8 is Ek_2,1inFIG. 5 and represents the recipient's public key (e.g., generated at202).

FIGS. 6-9 illustrate additional examples of the construction of an embodiment of a DSB.FIG. 6 illustrates an example of aDSB600.DSB600 encapsulates three subcomponents—part700 (the encrypted message, attachments, and controls), part800 (the symmetric key encrypted with each recipient's public key), and part900 (encrypted message parameters). As withDSB500, a symmetric key (shared byapp116 and platform102) is used to secure the DSB. In addition, the transmission of the DSB to the server is encapsulated with TLS for an additional security layer.FIG. 7 illustratespart700 ofDSB600. In particular,part700 includes the message controls (702), message (704), and attachments (706).Part700 is encrypted using a shared symmetric key SSK (e.g., Ek_1,1).FIG. 8 illustratespart800 ofDSB600. In particular,part800 includes the shared symmetric key, encrypted to each of the recipients' respective public keys. Further, the collection of encrypted keys (802-806) is encrypted using symmetric key SK1.FIG. 9 illustratespart900 ofDSB600. In particular,part900 includes encrypted message parameters.Part900 is encrypted using symmetric key SK2.

E. Receiving DSB Secured Messages

As mentioned above, Bob is also a user ofplatform102. When Bob loads his copy of the messaging app on his smartphone (i.e.,app138 on device114), the app communicates with platform102 (e.g., via interface118) to determine whether Bob has any new messages. Since Alice has sent a message to Bob since he last usedapp138, a flag is set indatabase120, indicating toapp138 that one or messages are available for download.

FIG. 10 illustrates an example of a process for accessing a message included inside a digital security bubble. In some embodiments,process1000 is performed on a client device, such as Bob'sclient device114. The process begins at1002 when a DSB is received. As one example, a DSB is received at1002 whenapp138contacts platform102, determines a flag associated with Bob's account has been set, and downloads the DSB fromplatform102. In such circumstances, upon receipt of the DSB,client114 is configured to decrypt the DSB using Bob's private key (e.g., generated by Bob at202 in process200).

At1004 (i.e., assuming the decryption was successful), hardware binding parameters are checked. As one example, a determination is made as to whether device information (i.e., collected from device114) can be used to construct an identical hash to the one included in the received DSB. If the hardware binding parameters fail the check (i.e., an attempt is being made to access Alice's message using Bob's keys on a device that is not Bob's), contents of the DSB will be inaccessible, preventing the decryption of Alice's message. If the hardware binding parameter check is successful, the device is authorized to decrypt the symmetric key (i.e., using Bob's private key generated at202) which can in turn be used to decrypt Alice's message.

F. Discouraging Screen Capture

As explained above, in addition to text messages (e.g., shown inregion304 ofFIG. 3), users can compose messages that include a variety of multi-media attachments (e.g., by interacting withregion308 ofFIG. 3). Returning to the example ofFIG. 3, suppose Alice attached a picture of her dog, Fido, to the message prior to sending to Bob. As explained above, and as illustrated inFIGS. 5 and 7, attachments to her message (i.e., the dog photograph) will also be encrypted, and can only be decrypted by intended recipients.

Some devices, such astablet device106 andphone114 provide native support for users of those devices to capture their screens. As one example, a user of an iOS device can capture what is being displayed on the device by holding down the menu button and, while the button is being held, also pressing the power/lock button. Alice may wish for Bob to be able to view her dog photograph for a limited time, and then have it no longer available to him. Unfortunately, if Bob uses the built-in screen capture feature of his phone while viewing Alice's picture, he'll be able to save a copy for later viewing.

In some embodiments,messaging app138 is configured to help mitigate screen capture attempts by users. An example of the process is shown inFIG. 12. In some embodiments, process1200 is performed on a client device, such as Bob'sclient device114. The process begins at1202 when x,y coordinates of one or more fingers are detected in an appropriate region. As one example,portion1104 ofinterface1100 includes a message to Bob, asking him to place his finger onicon1104 in order to view Alice's dog picture. When Bob does so, the x,y coordinates of his finger will be detected (at1202).

The x,y coordinates are checked every time they change (for example, when the finger touching the icon moves). If the move is more than a few pixels (e.g., more than 10 pixels), this can be indicative of a user attempting to manipulate the device and take a screen shot while also holding downicon1104. The attachment preview will accordingly end (at1204) if the change in finger position is too great, minimizing the possibility of a receiver taking unauthorized screen shots of attachments received in a secure message. Once an attachment preview has ended in this manner, in some embodiments, the user can view the attachment again (so long as it has not expired) by placing and holding a finger steady inregion1104.

In some embodiments, the number of pixels by which a finger may move without being considered an attempted screen capture is adjustable by the sender. For example, a sender can allow for more pixels (less sensitive) or fewer pixels (more sensitive) depending on the desired sensitivity. The number of pixels can also be determined by the application (e.g., based on the native resolution of the device, or other characteristics of the device, etc.).

In some embodiments, multiple screen areas or screen figures are required to be touched. This forces the user to hold more than one finger to tap and hold an area or areas, making it even more difficult to attempt to take a screen shot with the device.

Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims (20)

What is claimed is:

1. A system, comprising:

a processor configured to:

request an identifier associated with a first recipient, wherein the identifier comprises at least one of an application identifier and a device identifier;

encrypt a message, to be sent to at least the first recipient, using a first key;

encrypt the first key using a second key associated with the first recipient,

wherein the processor is configured to obtain the second key and the identifier from a server;

encapsulate the encrypted message, the encrypted first key, and the identifier in a digital security bubble encapsulation; and

transmit the digital security bubble encapsulation to the first recipient; and

a memory coupled to the processor and configured to provide the processor with instructions.

2. The system ofclaim 1 wherein the processor is further configured to generate the first key.

3. The system ofclaim 1 wherein the identifier comprises a device identifier.

4. The system ofclaim 3 wherein the device identifier is based at least in part on at least one hardware identifier.

5. The system ofclaim 1 wherein the identifier comprises an application identifier.

6. The system ofclaim 1 wherein the second key is a public key.

7. The system ofclaim 3 wherein the device identifier is based at least in part on a plurality of hardware identifiers associated with a plurality of hardware components.

8. The system ofclaim 1 wherein the processor is configured to request a plurality of public keys and a plurality of identifiers associated with a plurality of recipients.

9. The system ofclaim 8 wherein the processor is further configured to encrypt the first key with each of the received public keys, to produce a plurality of encrypted first keys.

10. The system ofclaim 9 wherein the digital security bubble encapsulation includes the plurality of encrypted first keys.

11. The method ofclaim 1 further comprising requesting a plurality of public keys and a plurality of identifiers associated with a plurality of recipients.

12. The method ofclaim 11 further comprising encrypting the first key with each of the received public keys, to produce a plurality of encrypted first keys.

13. A method, comprising:

requesting an identifier associated with a first recipient, wherein the identifier comprises at least one of an application identifier and a hardware identifier;

encrypting a message, to be sent to at least the first recipient, using a first key;

encrypting the first key using a second key associated with the first recipient, wherein the second key and the identifier are obtained from a server;

encapsulating the encrypted message, the encrypted first key, and the identifier in a digital security bubble encapsulation; and

transmitting the digital security bubble encapsulation to the first recipient.

14. The method ofclaim 13 further comprising generating the first key.

15. The method ofclaim 13 wherein the identifier comprises a device identifier.

16. The method ofclaim 15 wherein the device identifier is based at least in part on at least one hardware identifier.

17. The method ofclaim 13 wherein the identifier comprises an application identifier.

18. The method ofclaim 13 wherein the second key is a public key.

19. The method ofclaim 15 wherein the device identifier is based at least in part on a plurality of hardware identifiers associated with a plurality of hardware components.

20. A computer program product embodied in a tangible computer readable storage medium and comprising computer instructions for:

requesting an identifier associated with a first recipient, wherein the identifier comprises at least one of an application identifier and a hardware identifier;

encrypting a message, to be sent to at least a the first recipient, using a first key;

encrypting the first key using a second key associated with the first recipient, wherein the second key and the identifier are obtained from a server;

encapsulating the encrypted message, the encrypted first key, and an the identifier in a digital security bubble encapsulation; and

transmitting the digital security bubble encapsulation to the first recipient.

Images