Dynamic group membership of devices

Abstract

The present disclosure relates to dynamic group membership of devices. Some embodiments of the present invention provide a method for a first device to identify definitions of different device groups, each device group being defined by a set of attributes required for a device to become a member. The method monitors the attributes of the first device to determine when the device qualifies for membership in a group. When the first device qualifies for membership in a first group of which the device is not a member, the method sends a request for membership in the first group to at least one other device that is a member of the first group, the request signed with at least one private key of the device. When the first device becomes ineligible for membership in a second group of which the first device is a member, the method removes the device from the second group and notifies the other devices that are members of the second group.

Description

[0001] This application is a divisional application of PCT invention patent application No. 201680031639.3, which entered the Chinese national phase and whose international application date is March 31, 2016 and whose invention name is “Dynamic group membership of devices”. Background Art

[0002] Today, more and more users own multiple devices with overlapping functionality. Smartphones, tablets, and computers all have access to the internet, allowing users to work with photos and more, and users often own multiple such devices. Consequently, an increasing number of users desire to share data between their devices and access data on multiple devices. Users typically use a variety of different technologies to transfer data between devices, such as flash drives and email. More efficient technologies for automatically sharing data between user devices are desired. Summary of the Invention

[0003] Some embodiments provide a method for synchronizing data items between a group of related electronic devices. Specifically, some embodiments define an authentication subgroup that a device can join if the device meets the authentication subgroup's membership requirements, and use the authentication subgroup to define synchronization subgroups in which the device participates. In some embodiments, different synchronization subgroups define different types of data items that devices participating in the synchronization subgroup share with each other via a synchronization process.

[0004] In some embodiments, the group of related electronic devices includes all devices that the user has associated with a third-party service (e.g., with a specific cloud service account of the user). Knowledge of the cloud service account password is used as a membership requirement in at least one verification subgroup in some embodiments, while some embodiments define additional verification subgroups that various devices can join. Different embodiments define different sets of requirements for joining such additional verification subgroups, including requirements that the device have a specific operating system, have a specific level of password strength, have a secure processor, or other device configuration attributes. Some embodiments require devices to prove possession of specific cryptographic secrets in order to join a specific verification subgroup (e.g., possession of a key provided with an enterprise profile in order to join a verification subgroup defined by the enterprise), or that the user verify the membership of the new device on a device already established in the verification subgroup. In addition, some verification subgroups may require new devices to verify their own attributes to established devices via an out-of-band process (e.g., by using a third party for verification).

[0005] For a device to join a verification subgroup, some embodiments require that the device sign a request to join the subgroup and have one of the devices already in the verification subgroup approve the request. For example, in some embodiments, when a device meets the verification subgroup's requirement to possess a cryptographic secret, the device (i) signs its public key (which has been shared with other devices) and the date / time applied to the subgroup using a private key generated from the cryptographic secret, (ii) encapsulates the signature with its identity for joining the verification subgroup, and (iii) signs the identity using its own private key. The signature is then sent to the other devices in the subgroup as a request to join the verification subgroup. When one of the other devices verifies that the requesting device meets all the requirements to join the subgroup, the established device notifies the other devices in the verification subgroup, including the new device that has been added. In some embodiments, the notification includes a list of members of the verification subgroup, which includes the new device.

[0006] In some embodiments, a device may be a member of multiple verification subgroups. Furthermore, a device may be dynamically moved in and out of such verification subgroups as the device's attributes change, causing the device to either regain compliance with the requirements of various verification subgroups or to no longer meet the requirements. When a device's attributes change (e.g., a configuration file containing a particular cryptographic secret is installed on the device, a user changes the length of the device's passcode, etc.) such that the device becomes eligible to join a verification subgroup, the device generates and sends a request for membership in the verification subgroup, as described above. On the other hand, when a device's attributes change such that the device no longer meets the membership requirements of a verification subgroup of which the device is currently a member, the device detects that it should no longer be a member of that subgroup and transmits a notification of this to the other devices that are members of that subgroup.

[0007] In some embodiments, verification subgroups are used to organize devices into synchronization subgroups in order to determine which data items stored on a device should be synchronized with other devices. In some embodiments, a synchronization subgroup is defined by: (i) a set of requirements for devices participating in the synchronization subgroup, and (ii) a class of data items synchronized between the devices participating in the synchronization subgroup. In some embodiments, the set of requirements for a synchronization subgroup is membership in one or more verification subgroups. For example, the requirement for participating in a first synchronization subgroup may be membership in a first verification subgroup, while the requirement for participating in a second synchronization subgroup may be membership in both a second verification subgroup and a third verification subgroup.

[0008] Sync subgroups are used to enable groups of related devices to synchronize data items with each other. In various embodiments, these synchronized data items include usernames and passwords for online accounts (e.g., financial services websites, online forum websites, media content providers, online retail websites, etc.), encryption keys and / or secrets (i.e., data that can generate keys), network (e.g., Wi-Fi network) passwords, notes, photos, documents, and other files, etc. When one of the devices receives a new data item that is added to a group of synchronized data items (e.g., user input from a new password, the import or download of a new photo, etc.), the devices of some embodiments dynamically mark the data as belonging to one or more sync subgroups. For example, data may be marked based on the application that created the data (e.g., Wi-Fi network / password vs. online account username / password), the type of website accessible by the username / account (e.g., financial website vs. non-financial website), whether the data is related to a business, etc.

[0009] Data items belonging to a particular sync subgroup are synchronized between the devices participating in that particular sync subgroup. In some embodiments, each pair of devices creates a secure channel between themselves for sending data items (e.g., an informal (OTR) instant messaging protocol). In various embodiments, this secure channel may pass through a centralized service that allows temporary storage even when the receiving device is unlocked (e.g., storage for a cloud service account that both devices are logged into). However, in some embodiments, the use of a secure channel protects these communications from man-in-the-middle attacks. Other embodiments use a direct peer-to-peer connection (e.g., via Bluetooth).

[0010] When a first device determines that it should synchronize its data items to a second device, the first device identifies synchronization subgroups in which both the first device and the second device participate. For each such subgroup, the first device identifies all synchronization data items it stores that: (i) have not yet been transmitted to the second device, and (ii) belong to synchronization subgroups in which the second device participates. As long as the synchronization subgroup does not impose any additional requirements on the secure channel, the first device transmits the identified synchronization data items to the second device via the secure channel. When the synchronization subgroup imposes additional requirements on the secure channel (for example, encrypting the data items using an encryption key required to obtain verification of membership in the subgroup), the first device may synchronize the group of data items with the second device using multiple different secure channels. The second device also performs a similar set of operations to synchronize its data items to the first device.

[0011] This may cause devices to join and leave synchronization subgroups as they dynamically join and leave verification subgroups. For example, when a particular synchronization subgroup requires a device to be a member of both a first verification subgroup and a second verification subgroup, if the device loses its membership in the first verification subgroup, the device will no longer be able to participate in the particular synchronization subgroup even if it retains its membership in the second verification subgroup. In some embodiments, when a device is no longer eligible to participate in a particular synchronization subgroup, the device will remove all data items belonging to the particular synchronization subgroup (or prompt the user to decide whether the device should remove these data items), except for data items belonging to other synchronization subgroups in which the device still participates.

[0012] The above summary of the invention is intended to serve as a brief introduction to some embodiments of the present invention. It is not meant to be an introduction or overview of all the subject matter disclosed in this document. The subsequent detailed description and the drawings referenced in the detailed description further describe the embodiments described in the summary of the invention as well as other embodiments. Therefore, in order to understand all the embodiments described in this document, a comprehensive review of the summary of the invention, the detailed description and the drawings is required. In addition, the subject matter protected by the claims is not limited by the exemplary details in the summary of the invention, the detailed description and the drawings, but is limited by the appended claims, because the subject matter protected by the claims can be embodied in other specific forms without departing from the essence of the subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The novel features of the invention are set forth in the appended claims.For illustrative purposes, however, several embodiments of the invention are shown in the following drawings.

[0014] Figure 1 An example of six electronic devices that a single user may own is shown.

[0015] Figure 2 A first ring is shown with only a single criterion, which is that the device knows the user's cloud service account password.

[0016] Figure 3 A second ring is shown that requires membership of: (i) the device running the iOS operating system, and (ii) the user to approve the device's entry into the ring.

[0017] Figure 4 A third ring is shown requiring membership as follows: (i) the device has a password / password of at least 12 characters (used as a proxy for password / password strength), and (ii) the user approves the device's entry into the ring.

[0018] Figure 5 A fourth ring is shown requiring membership that the device (i) has the enterprise profile configuration installed, and (ii) knows the cloud service password.

[0019] Figure 6 A fifth ring is shown that requires membership that: (i) the device has a passcode, and (ii) the device is authenticated as a trusted Apple device using an out-of-band process.

[0020] Figures 7 to 9 Shown Figure 1 Examples of different views of a device group, each based on Figures 2 to 6 Membership in one or more rings is defined.

[0021] Figure 10 The software architecture of device 1000 is conceptually illustrated for some embodiments of grouping devices into verification subgroups (rings) and synchronization subgroups (views).

[0022] Figure 11 A process 1100 of some embodiments for requesting membership in a ring is conceptually illustrated.

[0023] Figure 12 A process 1200 of some embodiments for determining whether to allow a device into a ring is conceptually illustrated.

[0024] Figure 13 Conceptually illustrated is a first device requesting to join a ring and being approved by a second device.

[0025] Figure 14 Devices are conceptually shown joining the ring, which requires verification of device attributes by a central authority as well as possession of secret encryption keys.

[0026] Figure 15 A process 1500 is conceptually illustrated for some embodiments of synchronizing key chain data from a first device to a second device.

[0027] Figure 16 Receipt of a new data item for synchronization by the first device is shown.

[0028] Figure 17 Shown Figure 16 The new data item is synchronized from the first device to the second device.

[0029] Figure 18 and Figure 19 A data protection structure is shown where an application-specific private key is used to access data stored in a tree of key and data fields, ultimately allowing access to the application data itself.

[0030] Figure 20 Conceptually illustrated are processes of some embodiments for dynamically modifying a device's ring membership and subsequent view participation.

[0031] Figures 21A to 21B Shows what happens when the password of one of the devices has been changed, removing it from the ring. Figure 16 and Figure 17 equipment.

[0032] Figure 22 An example of an architecture for a mobile computing device with which some embodiments may be implemented is shown.

[0033] Figure 23 Another example of an electronic system with which some embodiments of the present invention may be implemented is conceptually illustrated. DETAILED DESCRIPTION

[0034] In the following detailed description of the invention, many details, examples and embodiments of the present invention are proposed and described. However, it will be clear and apparent to those skilled in the art that the invention is not limited to the embodiments set forth, and that the invention can be practiced without using some of the specific details and examples discussed.

[0035] Some embodiments provide a method for synchronizing data items between a group of related electronic devices. Specifically, some embodiments define an authentication subgroup that a device can join if the device meets the authentication subgroup's membership requirements, and use the authentication subgroup to define synchronization subgroups in which the device participates. In some embodiments, different synchronization subgroups define different types of data items that devices participating in the synchronization subgroup share with each other via a synchronization process.

[0036] In some embodiments, the group of related electronic devices includes all devices that the user has associated with a third-party service (e.g., with a particular cloud service account of the user). Knowledge of the cloud service account password is used as a membership requirement in at least one authentication subgroup (also referred to herein as a ring) for some embodiments, while some embodiments define additional rings that various devices can join. In some cases, a user may own or use multiple smartphones, smart watches, tablets, laptops, desktop computers, media players, etc., all of which are logged into the user's cloud service account and have different properties.

[0037] Different implementations define different sets of requirements for joining such additional rings, including requirements that the device have a specific operating system, a specific level of cryptographic strength, specific hardware (e.g., a secure processing unit such as the Apple Secure Enclave processor), or other device configuration attributes. Some implementations require a device to prove possession of a specific cryptographic secret in order to join a specific ring (e.g., possession of a key provided with an enterprise configuration profile in order to join a ring defined by the enterprise), or for a user to verify the new device's membership on a device already established in the ring. Additionally, some rings may require a new device to verify its own attributes to an established device via an out-of-band process (e.g., by using a third party for verification), with the ring serving as a persistent proof of the device's attributes at the specific time it joins the ring.

[0038] For a device to join a ring, some embodiments require the device to sign a request to join the ring and have one of the devices already in the ring approve the request. For example, in some embodiments, when a device meets the ring's requirement to possess a cryptographic secret, the device (i) signs its public key (which has been shared with other devices) and the date / time it was applied to the ring using a private key generated from the cryptographic secret, (ii) encapsulates the signature with its identity for joining the ring, and (iii) signs the identity using its own private key. The signature is then sent to the other devices in the ring as a request to join the ring. When one of the other devices verifies that the requesting device meets all the requirements to join the ring, the established device notifies the other devices in the ring, including the new device that was added. In some embodiments, the notification includes a list of members of the ring, which now includes the new device.

[0039] In some embodiments, a device can be a member of multiple rings. Furthermore, a device can be dynamically moved in and out of such rings as the device's properties change, causing the device to re-meet the requirements of various rings or no longer meet the requirements. When a device's properties change (e.g., a configuration file containing a particular cryptographic secret is installed on the device, a user changes the length of the device's passcode, etc.) such that the device becomes eligible to join a ring, the device generates and sends a request for membership in the ring, as described above. On the other hand, when a device's properties change such that the device no longer meets the membership requirements of a ring of which the device is currently a member, the device detects that it should no longer be a member of that ring and transmits a notification of this to the other devices that are members of the ring.

[0040] In some embodiments, rings are used to organize devices into synchronization subgroups (also referred to herein as views) in order to determine which data items stored on a device should be synchronized with other devices. In some embodiments, a view is defined by: (i) a set of requirements for devices participating in the view, and (ii) a class of data items that are synchronized between devices participating in the view. In some embodiments, the set of requirements for a view is membership in one or more rings. For example, the requirement for participating in a first view may be membership in a first ring, while the requirement for participating in a second view may be membership in both a second ring and a third ring.

[0041] Views are used to enable groups of related devices to synchronize data items with each other. In various embodiments, these synchronized data items include usernames and passwords for online accounts (e.g., financial services websites, online forum websites, media content providers, online retail websites, etc.), encryption keys and / or secrets (i.e., data that can generate keys), network (e.g., Wi-Fi network) passwords, notes, photos, documents and other files, etc. When one of the devices receives a new data item that is added to the group of synchronized data items (e.g., user input from a new password, the import or download of a new photo, etc.), the devices of some embodiments dynamically mark the data as belonging to one or more views. For example, data may be marked based on the application that created the data (e.g., Wi-Fi network / password vs. online account username / password), the type of website accessible by the username / account (e.g., financial website vs. non-financial website), whether the data is related to a business, etc.

[0042] The data items belonging to a particular view are synchronized between the devices participating in that particular view. In some embodiments, each pair of devices creates a secure channel (e.g., an informal (OTR) instant messaging protocol) between themselves for sending data items. In different embodiments, this secure channel can pass through a centralized service (e.g., a memory of a cloud service account logged in by two devices) that allows temporary storage even when the receiving device is unlocked. However, in some embodiments, the use of a secure channel protects these communications from man-in-the-middle attacks. Other embodiments use a direct peer-to-peer connection (e.g., via Bluetooth connection). The synchronization of data items for key chains is described in more detail in U.S. Patent Publication 2014 / 0281540.

[0043] When a first device determines that it should synchronize its data items to a second device (e.g., based on user input, a particular time period that has passed, etc.), the first device identifies views in which both the first device and the second device participate. For each such view, the first device identifies all synchronized data items that it stores that: (i) have not yet been transmitted to the second device, and (ii) belong to views in which the second device participates. As long as the view does not impose any additional requirements on the secure channel, the first device transmits the identified synchronized data items to the second device via the secure channel. When the view imposes additional requirements on the secure channel (e.g., encrypting the data items using an encryption key required to obtain verification of membership in a subgroup), the first device may synchronize the set of data items with the second device using multiple different secure channels. The second device also performs a similar set of operations to synchronize its data items to the first device.

[0044] When devices dynamically join and leave rings, this may cause devices to join and leave views. For example, when a particular view requires a device to be a member of a first ring and a second ring, if the device loses its membership in the first ring, the device will no longer be able to participate in the particular view even if it retains its membership in the second ring. In some embodiments, when a device is no longer eligible to participate in a particular view, the device will remove all data items belonging to the particular view (or prompt the user to decide whether the device should remove these data items), except for data items belonging to other views in which the device is still participating.

[0045] The foregoing describes examples of data synchronization systems for some embodiments. Several more detailed examples are described below. Section I describes a set of devices, and examples of rings and views that can be defined for the devices. Next, Section II describes the device architecture for some embodiments for enabling rings and views. Section III then describes the ring joining process for some embodiments, while Section IV describes the synchronization of data for different views. Next, Section V describes dynamically evaluating ring status and the consequences of view participation in some embodiments. Finally, Section VI describes the electronic system utilized to implement some embodiments of the present invention.

[0046] I. Ring and View Examples

[0047] As described above, some embodiments define rings of device groups that a device can join based on static or dynamic properties of the device. In various embodiments, these rings can be defined by the device's manufacturer, third-party developers, or the users themselves. For example, a manufacturer that sells a variety of different types of user devices (a single user may own any number of user devices) can integrate ring definitions into the device operating system. On the other hand, third-party developers or users may propose additional rings that they find useful and design these rings for some or all devices. In some embodiments, the manufacturer provides a framework for the device that allows users to arbitrarily define rings for their personal devices, where the framework has the ability to convert arbitrarily defined rings into functional ring definitions.

[0048] Device manufacturers, third-party developers, or users can also organize devices into views based on ring membership, as described above. That is, a device's participation in a particular view can be defined based on whether the device is a member of one or more rings. In some embodiments, views can also be defined by reference to device attributes other than ring membership, while other embodiments restrict views to definitions based on ring membership. In some embodiments, in addition to defining ring membership criteria, users also have the ability to define which data is shared for a particular view and which rings a device must belong to in order to participate in that particular view (i.e., to synchronize specified data with other devices).

[0049] Figure 1 An example of six electronic devices 105-130 that a single user may own is shown. As shown, these six electronic devices include a first smartphone 105, a second smartphone 110, a tablet computer 115, a laptop computer 120, a streaming video set-top box 125, and a desktop computer 130. In this case, the first smartphone 105 and the laptop computer 120 are the user's work devices, while the other four devices 110, 115, 125, and 130 are the user's personal devices. Each of these devices has different properties, some of which are shown in the accompanying drawings.

[0050] Specifically, the first smartphone 105 (which may be, for example, an iPhone 6) (i) knows the user's cloud service account password (because the user is logged into the cloud service account on the device), (ii) has a built-in fingerprint scanner, (iii) runs the iOS operating system, (iv) has a remote wipe feature enabled to allow the user to remotely instruct the phone to wipe its memory if the phone is lost, (v) has a passcode that is at least 12 characters long for unlocking the device, and (vi) has an enterprise configuration installed. Thus, the fingerprint scanner, the long unlock passcode, and the remote wipe feature all indicate that the device is a secure device. Furthermore, the installation of the enterprise configuration of some embodiments provides the device with a specific cryptographic secret, thereby enabling the generation of a public / private key pair.

[0051] The second smartphone 110 (which may be, for example, an earlier iPhone) (i) knows the user's cloud service account password, (ii) runs the iOS operating system, (iii) has the remote wipe feature enabled, and (iv) has a 4-character passcode for unlocking the device. Smartphone 110, with its shorter passcode and lack of a fingerprint scanner, is less secure than first smartphone 105, but still quite secure.

[0052] Tablet computer 115 (e.g., iPad) (i) knows the user's cloud service account password, (ii) runs the iOS operating system, and (iii) has a 4-character password for unlocking the device. Laptop computer 120 (e.g., MacBook) (i) knows the user's cloud service account password, (ii) runs the Mac OS X operating system, (iii) has a 12-character password for unlocking the device, and (iv) has an enterprise configuration installed. Streaming video set-top box 125 (e.g., Apple TV) only knows the user's cloud service account password. Finally, home desktop computer 130 (e.g., iMac) (i) knows the user's cloud service account password, (ii) runs the Mac OS X operating system, and (iii) has a 12-character password for unlocking.

[0053] The attributes listed for various devices 105-130 represent a few examples of ring membership criteria (e.g., whether the user is logged into a cloud service account, the device's operating system, password strength, other security features, provision of cryptographic secrets via enterprise configuration, etc.). Those skilled in the art will recognize that many other criteria can be used to determine ring membership eligibility. As will be shown, some of these criteria are not device attributes. For example, some embodiments use attributes of applications running on the device as ring membership criteria (e.g., whether the application is installed, how the application is configured on the device, etc.). Furthermore, some embodiments require certain user actions in order to join the ring, such as a user approving another device on a device already established in the ring, a user entering a code provided by an established device on the requesting device, etc. Furthermore, some ring memberships require third-party verification. For example, some embodiments require a third party to attest that the device is a valid iOS device. On the other hand, some ring membership criteria must simply be asserted by the device requesting membership (e.g., the device password is at least a certain length).

[0054] Figures 2 to 6 Examples of various rings are provided for some embodiments of devices 105-130. Figure 2A first ring 200 is shown with only a single criterion: that the device knows the user's cloud service account password. Some embodiments use this ring to allow all devices owned by a user to join the ring together, as long as the user logs the device into the cloud service account. In some embodiments, a new device can be added to the ring by generating a private key based on the account password using a deterministic public / private key generation algorithm and signing an application with the private key (which can be verified by any device already in the ring). In this way, all devices 105-130 are members of the first ring 200.

[0055] Figure 3 A second ring 300 is shown requiring membership as follows: (i) the device running the iOS operating system, and (ii) user approval of the device's entry into the ring. Thus, not just any iOS device (i.e., a random user's smartphone) can join the ring; instead, the user who established the device must approve its inclusion in the ring. While user approval provides an example of a security mechanism to prevent non-user devices from joining, some embodiments require knowledge of the cloud service account password (or another cryptographic secret) for all rings to prevent a user from accidentally allowing another user to join the ring with their actual device. In some embodiments, as part of the ring joining process, the device declares that it is an iOS device; the user is then presented with a prompt to not only approve that the device belongs to the user, but also that it is the iOS device claimed in the ring membership request (e.g., a prompt stating, "iPhone would like to join your iOS device ring; please verify this is your iPhone" or similar). In other embodiments, the device is required to verify with a third party (e.g., the device manufacturer) that it is the claimed iOS device. This verification can be performed out-of-band before approving the device for ring entry. The second ring 300 has three members, namely the two smartphones 105 and 110 and the tablet 115 , since the other three devices are not iOS devices.

[0056] Figure 4 A third ring 400 is shown that requires the following membership requirements: (i) the device has a password / password of at least 12 characters (serving as a proxy for password / password strength), and (ii) user approval of the device to enter the ring. As with the previous ring 300, once a sufficiently long password is present, the user approval requirement prevents any random user device from joining the ring. Furthermore, as described for ring 300, in some embodiments, a prompt for the user to approve a device as having a secure password / password is displayed on the user's established device. This ring 400 has three members: a first smartphone 105, a laptop computer 120, and a home desktop computer 130.

[0057] Figure 5A fourth ring 500 is shown that requires the device to (i) have the enterprise profile configuration installed, and (ii) know the cloud service password. In some embodiments, the device can prove possession of the enterprise profile configuration by signing a membership request to join the ring using a private key provided as part of the enterprise profile, a process described below with reference to Figure 13 This is described in more detail. When a new device requests ring membership by sending a signed membership request, one of the established devices verifies the request using the enterprise profile public key. The cloud service password restricts membership to only devices owned by a specific user, not any individual member of the enterprise. This serves as a verification mechanism to ensure the user approves the device joining the ring (by entering the cloud service password). Since only two of the user's devices have the enterprise profile installed, ring 500 only includes smartphone 105 and laptop 120.

[0058] at last, Figure 6 A fifth ring 600 is shown that requires the following membership: (i) the device has a passcode, and (ii) the device is authenticated as a trusted Apple device using an out-of-band process. Some embodiments require various out-of-band attestations of different ring memberships, requiring a third party to attest to some aspects of the requesting device's claims in order for the established device to allow the requesting device to enter the ring. For example, such third-party verification can be used to prove the validity of the device, the presence of a secure processor on the device, etc., any of which can be a ring membership requirement. While out-of-band verification of membership criteria only verifies that the membership criteria is true at a particular time, the existence of the ring enables persistent attestation of the claimed criteria without the need for periodic third-party verification. For this ring, since all devices 105-130 are Apple devices, all devices with passcodes (smartphones 105 and 110, tablet 115, laptop 120, and desktop computer 130) are able to join the ring 600.

[0059] In the above embodiments, the membership of a requesting device in any ring is contingent in one way or another on verification of membership criteria by devices already established in the ring. Some embodiments implement three different levels of rings: (1) self-declaring rings, which any device can join simply by declaring membership, (2) application rings, which require devices to declare membership and prove knowledge of a cryptographic secret, and (3) conformance rings, which require self-declaration (and, in some cases, knowledge of a cryptographic secret) as well as approval by devices already established in the ring.

[0060] In some embodiments, self-declaring rings generally do not provide a significant amount of security and are therefore not generally used for development view requirements (i.e., a device simply declaring facts about itself does not give the device access to any additional synchronization data). Instead, unverified declarations of these facts can be part of a device's identity used in membership requests for application and consistency rings. An example of a self-declaring ring is one where the only membership criteria is that the device declares its existence or that it has a password; once a device makes such a declaration, the device is automatically added to the ring.

[0061] In some embodiments, an example of an application ring is one that requires an enterprise key but does not perform additional authentication. Thus, to join the ring, a device must prove that it possesses the enterprise key (e.g., by signing an application with a private key). However, such a ring does not require additional levels of authentication. For example, a user does not have to approve such devices, so any device that possesses the cryptographic secret (and therefore can generate the required key) can join the ring.

[0062] Finally, a consistency ring is the most commonly used ring type for defining views (i.e., a group of devices synchronizing a specific type of data). As mentioned above, a consistency ring requires devices to request ring membership and explicitly authenticate applications on devices established in the ring (e.g., by prompting the user for approval). A consistency ring may also require proof of a specific cryptographic secret (e.g., a key generated based on the user's cloud service password, enterprise key, etc.), but once the signature generated by that key is verified by the established device, the established device will prompt the device's user to verify whether the requesting device should join the ring.

[0063] Additionally, some embodiments may use various out-of-band user interaction techniques to verify whether a device should be in the ring (e.g., out-of-band attestation of a cryptographic secret). For example, some embodiments allow an established device to generate a cryptographic secret and rely on the user to bring that secret to the requesting device so that the established device trusts the requesting device. As an example, the established device may generate a random number from which a public / private key pair may be generated. When the user enters the random number on the requesting device, the requesting device may generate a private key and sign the ring membership request using the generated private key. Similarly, the established device may generate audio or image data (e.g., a Quick Response (QR) code) and require the requesting device to capture that data and, from that data, generate a public / private key pair in a deterministic manner. Those of ordinary skill will recognize that a variety of such techniques may be used, depending on the two types of devices involved (e.g., a smartwatch taking a picture of a QR code generated on a phone, one device being moved near another in a specific manner, etc.).

[0064] Rings allow devices to verify that other devices possess specific attributes and to store proof of those attributes, eliminating the need for devices to periodically verify attributes. Using rings, some embodiments enable devices to form one or more synchronization subgroups, or views, that allow devices to share specific data items with devices that have verified certain attributes. Thus, in some embodiments, participation in each view is defined based on membership in one or more rings; that is, only devices that meet the view's requirements (by being accepted as members in one or more designated rings) can share synchronized data associated with the view.

[0065] The view enables layering of different types of data that can be synchronized between a user's devices. As an example, a user may want to share certain data across all of her devices (e.g., most photos, non-sensitive documents, passwords or credit card numbers that cannot access financial information, etc.). On the other hand, the user may want to keep other data (e.g., sensitive photos, encrypted documents, passwords to financial websites, or e-commerce websites that store the user's credit card information) away from less secure devices (e.g., streaming video set-top boxes that are not password-protected). Furthermore, some data may not be usable on certain types of devices (a password for a mobile app may be useless on a laptop or desktop computer that does not support such an app).

[0066] Figures 7 to 9 Shown Figure 1 600. Some embodiments allow view requirements to be based solely on ring membership, while other embodiments also allow other types of requirements for device participation in a view (e.g., device attributes, such as those described above as ring membership requirements). In this sense (defining view requirements based on ring membership), a ring is similar to a certificate authority in that it is used to attest to certain attributes of a device, which the device can then use to trust other devices for synchronization purposes.

[0067] like Figure 7 As shown, participation in the first view 700 is defined by membership in the first ring 200. Therefore, all six devices 105-130 participate in the first view. The figure shows that the six devices 105-130 are connected in a full mesh framework, where each device is able to synchronize with all other devices. As described in U.S. Patent Publication No. 2014 / 0281540, some embodiments use full mesh connections to synchronize between user devices, while other embodiments use other network configurations (e.g., a star network with one device acting as a central hub).

[0068] The figure indicates that three data items 705-715 belong to the first view 700. In some embodiments, as Figure 7As shown, each data item stored on the device is tagged with view information that specifies which view the data item belongs to (for each data item, it is the type that is synchronized with the device; data items that are not eligible for synchronization are not marked as such). When a device in the device receives a new data item to be added to the set of synchronized data items (for example, by the user entering a new password, importing a new photo from the camera, or creating a new document, etc.), the device dynamically marks the data as belonging to one or more views. For example, data may be tagged based on the application that created the data (for example, Wi-Fi network / password vs. online account username / password), the type of website that the username / account can access (for example, financial websites vs. non-financial websites), whether the data is related to an enterprise, etc., depending on how the views are defined for the device group.

[0069] In some embodiments, three data items 705-715 are stored on each of the three devices. Once one of the devices receives one of these data items, that device shares the data item with the other devices via separate encrypted channels (i.e., separate channels between each pair of devices). Thus, if a user first enters password item 715 on desktop computer 130, the desktop computer shares the item with each of the other devices 105-125 via separate channels. In some embodiments, these channels are encrypted using password-authenticated key exchange (PAKE), such as informal (OTR) instant messaging, as described in more detail below and in U.S. Patent Publication No. 2014 / 0281540.

[0070] As also described in U.S. Patent Publication No. 2014 / 0281540, in some embodiments, the peer-to-peer connection uses a cloud service intermediary. That is, for a device (e.g., smartphone 105) to share a data item 705 with a second device (e.g., tablet 115), the sending device sends the data item to the cloud service's intermediate storage (encrypted using the public key for the connection between the two devices). The second device then retrieves the data item from the intermediate storage and decrypts it. Using PAKE allows devices to share synchronized data items in this manner without making the cloud service owner vulnerable to man-in-the-middle attacks.

[0071] The first view 700 includes all devices, Figure 8A second view is shown that requires membership in both the third ring 400 and the fourth ring 500 to participate. This view essentially requires that the device be authenticated as an enterprise device (i.e., have an enterprise profile installed) and have a highly secure password (at least 12 characters, with the length used as a security proxy). Only two devices, the smartphone 105 and the laptop 120, participate in this view. As shown, the view includes three data items 805-815, each of which is marked as belonging to the second view (V2). For example, if a data item is related to certain enterprise applications or is represented by the user as a work-related file, the data item may be marked as belonging to the second view 800. In this case, the addition of membership in the third ring 400 ensures that the user does not change one of their passwords to a shorter, less secure password, as doing so would result in being kicked out of the third ring 400 and therefore kicked out of view 800. In addition, one of the data items 815 is marked as belonging to both the second view V2 and the third view V3. In some embodiments, a data item can belong to multiple views and be shared to devices belonging to any of these views.

[0072] at last, Figure 9 A third view 900 is shown that requires membership in both the second ring 300 and the fifth ring 600 (i.e., requires the device to be an iOS device that has been verified as a trusted Apple device with a passcode). Three devices 105-115 participate in the third view 900, and two data items 815 and 905 are shared between each two of these devices. Even if these devices do not participate in the second view 800, the data item 815 will be synchronized to devices 110 and 115. In other embodiments, this requires the device to be a member of each view to which the data item belongs, and the smartphone 105 will not be allowed to share the data item 815 with any other device.

[0073] Some embodiments allow for customization of the hierarchy of synchronized data items by third-party developers or by users of the device itself. For example, some embodiments provide developers with a toolkit for designing rings and / or views for data associated with a particular application. For example, a developer of an enterprise application can design requirements for devices that will share data items associated with the enterprise application (i.e., can specify specific password strengths or other device requirements). In some embodiments, the device includes a user interface for enabling users to customize how their devices synchronize data. That is, users can design different views for their data items based on a set of possible requirements, and the device will implement the user's selections by grouping the rings into views. However, in other embodiments, the design of the rings and views is performed by the device manufacturer that designs the devices for the group of users.

[0074] II. Device Architecture

[0075] Figure 10 The software architecture of a device 1000 for some embodiments of grouping devices into authentication subgroups (rings) and synchronization subgroups (views) is conceptually illustrated. In this case, device 1000 is one of several (N) devices associated with a cloud service account. For the discussion in this and subsequent sections, it will be assumed that the various devices that join the ring and share data items through a view are all associated with a single user (e.g., via a cloud service account or other user authentication mechanism). Therefore, in addition to device 1000, Figure 10 Also shown is a set of additional devices (D2-D N ) 1005. Device 1000 and other devices 1005 can be any different types of electronic devices capable of storing data and communicating with a network. For example, these devices may include smartphones, tablets, laptop and / or desktop computers, smart watches, set-top boxes (separate from or integrated into a TV), virtual devices (e.g., virtual machines) operating on another device, etc.

[0076] As shown, device 1000 includes a synchronization engine 1010, a ring evaluator 1015, a view evaluator 1020, a data tagger 1025, and a set of applications 1030. Furthermore, the device includes storage for keychain data items 1035, device and ring signing keys 1040, and view and ring requirements and descriptions 1045. These memories can all be part of the same physical memory (e.g., a hard drive, solid-state memory, random access memory, etc.) or separate physical memories (e.g., keys can be stored in a more secure memory than view and ring requirements / descriptions). Furthermore, some data can be embedded in the module's code. For example, if the view description and requirements are fixed, this information can be part of the view evaluator and data tagger, rather than separate data pulled from memory by these modules.

[0077] In some embodiments, the key chain data store 1035 stores key chain data items that are data items synchronized between the device 1000 and another device 1005. In some embodiments, these data items are stored on the device encrypted with a public key associated with the device 1000 (and stored on the other devices encrypted with the public keys of the other devices). In some embodiments, the public key is a device-specific key generated by the device in a secure manner when the device is initially formatted. In addition, in some embodiments, each data item stored on the device is marked as belonging to one or more views.

[0078] In some embodiments, device and ring signing key storage 1040 stores various keys used by the device for data storage, data synchronization, and ring membership joining / verification. For example, some embodiments use device keys to encrypt data items for storage on device 1000 and also for restoring data backed up by one of devices 1000 or 1005, as described in greater detail in U.S. Provisional Patent Applications 62 / 168,894 and 62 / 172,128, and U.S. Patent Application 14 / 871,498, entitled "Backup System with Multiple Recovery Keys." As described in further detail below, key storage 1040 may also store ring signing keys (e.g., keys generated from shared user credentials (e.g., cloud service account passwords), enterprise or other keys used to join various different rings), and keys used to protect synchronized data items during inter-device transmission (i.e., keys for the PAKE-protected channel between device 1000 and each of devices 1005). In some embodiments, these keys may be stored in various locations on device 1000, rather than in a single memory location. For example, some keys may be stored in a secure processor separate from the standard operation of device 1000.

[0079] The view and ring requirements and description memory 1045 conceptually stores requirements for different rings defined by third-party developers, device manufacturers, or users. As described in the previous section, these requirements can include the possession of various credentials and / or encryption keys (e.g., shared user passwords or other credentials, enterprise keys, etc.), declarations of various device and / or application attributes (e.g., password length, operating system, application configuration, etc.), out-of-band verification of various attributes (e.g., operating system, device validity, etc.), or various user actions (e.g., entering a code shown on one device, moving another device near one device, taking a picture of another device using one device, etc.). The memory 1045 also stores view requirements, which in some embodiments identify which rings a particular device (i.e., device 1000 or one of the other devices 1005) must be a member of in order to participate in each different view. In addition, the memory 1045 includes view descriptions, which identify, for each view, which types of data items belong to that view. The view description can identify the data item for the view based on various characteristics, including from which application the data item was received (e.g., a password from a Wi-Fi application for a first view, a password from a web browser application for a second view), which World Wide Web domain the password is associated with (e.g., a password from a comprehensive list of financial website domains assigned to a particular view). In some embodiments, the view description simply specifies the data items that are marked as belonging to a particular view, and the user selects from a list of views when first entering the data item.

[0080] In some embodiments, a user of the device 1000 can enter keychain data through an application 1030. The applications 1030 may include third-party applications (e.g., banking applications, gaming applications, streaming video applications, etc.) as well as applications that are integrated with the device operating system and come from the device manufacturer (e.g., a built-in browser or mail application, a Wi-Fi application, etc.). The user enters a username and password or other keychain data through these applications 1030. In addition, the application can receive keychain data in other ways (e.g., by generating an encryption key, capturing a photo, etc.). In some embodiments, the keychain data 1050 captured by the application 1030 is sent to the data tagger 1025.

[0081] The data tagger 1025 handles tagging of key chain data 1050 received from the application 1030 (and key chain data items from any other source when the data items are not already tagged with view information). In some embodiments, as shown, the data tagger 1025 pulls view description information 1055 from the view description and requirements store 1045 and uses this information to determine to which view each of the key chain data items 1050 belongs. In other embodiments, as described above, the view description is part of the data tagger code and does not need to be retrieved from storage.

[0082] The data tagger 1025 appends the view information to the key chain data. In some embodiments, the data tagger sends the view-tagged key chain data 1060 to the synchronization engine 1010 (as shown), which encrypts the data item using an encryption key and function and stores it in the key chain data storage 1035. In other embodiments, the data tagger encrypts the view-tagged key chain data 1060 using an encryption function and stores the data directly to the storage 1035 without involving the synchronization engine 1010. In either case, some embodiments encrypt the data item but not the view tag, so that the view to which the data item belongs can be identified (e.g., by the synchronization engine 1010) without decrypting the data.

[0083] Ring evaluator 1015 (i) generates requests for device 1000 to join a ring, and (ii) evaluates requests from other devices 1005 to join a ring of which device 1000 is already a member. To generate requests, ring evaluator 1015 of some embodiments includes self-evaluator module 1016. This module uses ring requirements 1065 to determine when device 1000 meets the membership criteria of a ring. Ring requirements 1065 can be part of the ring evaluator code (e.g., if hard-coded by the device manufacturer) or retrieved from memory 1045 (e.g., if defined by the device user or by a third-party developer). In some embodiments, self-evaluator 1016 periodically checks to determine whether device 1000 has changed in a way that causes it to meet the requirements of a ring of which it is not yet a member, or no longer meet the requirements of a ring of which it is already a member. In other embodiments, self-evaluator 1016 operates in an event-driven manner. That is, when device properties (or other criteria that affect ring membership) change, self-evaluator 1016 is notified to determine whether the device's ring status should change.

[0084] When the self-evaluator 1016 identifies that the device meets the criteria for joining a new ring (rather than any request-driven action, such as user approval of ring membership or porting of code from one of the devices 1005 to the device 1000 (or vice versa)), the ring evaluator 1015 generates and signs a ring join request 1070 using any keys 1067 required for the ring request (e.g., the device public key used as part of the device identity, the device private key, and / or any ring-specific keys used to sign the request). Details of such requests are described below with reference to Figure 13 Although not shown in the figure, the ring evaluator 1015 may also send a notification to other devices when the self-evaluator 1016 determines that a device should no longer be a member of a particular ring.

[0085] The ring evaluator 1015 also includes a credential checker module 1017 for validating ring join requests 1075 received from other devices 1005. As with device 1000, when one of the other devices determines that it meets the criteria for joining a ring, it generates a ring join request and sends it to the other devices in the ring (in some embodiments, each device stores a list of devices in each ring, including rings of which it is not a member). When device 1000 receives such a request, the credential checker 1017 verifies whether the requesting device should be allowed to join the ring it is requesting to join. This may require verifying that the request has been signed with one or more appropriate keys, verifying that any out-of-band criteria have been met or performing out-of-band checks (e.g., checking that the requesting device is a valid device, that a code generated on device 1000 has been correctly entered on the requesting device, etc.), whether the device has correctly declared its criteria for joining the ring, whether the user of device 1000 has approved the requesting device, etc. When the ring join request is validated, the ring evaluator 1015 sends a ring status message (not shown) to the other devices 1005 in the ring. In some embodiments, the ring status message is a list of devices in the ring, including recently added devices. This is used to notify the requesting device that it has successfully joined the ring and to notify other devices that device 1000 has approved the requesting device's membership (so they do not need to process membership requests separately). In some embodiments, the notification message is signed with the private key of a ring-specific key pair (e.g., the key used to sign the membership request).

[0086] The ring evaluator 1015 also periodically keeps the view evaluator 1020 informed of the current ring state 1080 of the device 1000 and other devices 1005. In some embodiments, the view evaluator 1020 requests this information from the ring evaluator 1015 (or from a memory where the ring evaluator stores this information) as needed. The view evaluator 1020 is responsible for determining which devices (including the device 1000 and other devices 1005) participate in each different view defined for the group of devices. Specifically, in some embodiments, the view evaluator determines (at any given point in time, based on the current ring membership status of all devices) the mapping between views and devices (i.e., for each device, which views the device participates in; or for each view, which device participates). The view evaluator 1020 makes this determination based on view requirements 1085, which again may be coded into the view evaluator by the device manufacturer or, in various embodiments, variable information generated by third-party developers and / or users.

[0087] In addition to defining which rings a device must be a member of in order to participate in a view, the view requirements of some embodiments may specify any requirements for the channel used to synchronize the view's data between devices (for some or all views). As described above, in some embodiments, devices form a peer-to-peer encrypted channel using, for example, PAKE (which relies on a shared key over which data items are encrypted during synchronization). Furthermore, some views require devices to be members of a ring, which itself requires possession of a public / private key pair. Some such views require that the channel between two devices use this key in addition to the shared key of PAKE. For example, for an enterprise view that requires membership in an enterprise ring (which requires possession of an enterprise private key), some embodiments use the enterprise private key to encrypt data items synchronized for that view. Thus, the view evaluator 1020 provides the synchronization engine 1010 with (i) a mapping 1090 between views and devices, and (ii) the requirements 1095 for the synchronization channel for each view.

[0088] In some embodiments, the synchronization engine 1010 is responsible for synchronizing the view-tagged keychain data items with the other device 1005. In some embodiments, the synchronization engine 1010 determines that it should synchronize the data item with the other device and receives a list 1090 of views in which the specific other device participates and any special channel requirements for each view from the view evaluator 1020. In some embodiments, the synchronization engine 1010 synchronizes only one channel at a time and therefore only requests from the view evaluator 1020 a list of views that use a specific channel between the device 1000 and the other device (if there are no special channel requirements, then this will be all views in which both the other device and the device 1000 participate). The synchronization engine 1010 retrieves the view-tagged keychain data items 1097 belonging to the correct view from the keychain data store 1035 and synchronizes these data items to the other device via a secure channel. In some embodiments, this requires removing the encryption on the keychain data items used during storage on the device and re-encrypting the keychain data items using the shared key for the secure channel.

[0089] Those skilled in the art will recognize that the module group shown in the figure is a subset of the software architecture of the device, which will include a variety of modules for any number of purposes. In addition, many of the modules shown in the figure will themselves include several modules, and various modules that can be reused by several of the shown modules are not shown. For example, when used with other devices (as described below by reference Figure 16 and Figure 17 ) and a Ring Evaluator (used to sign Ring applications and / or verify Ring applications of other devices, as shown below Figure 13 When synchronizing data (as shown), the synchronization engine may use encryption and / or decryption functions.

[0090] III. Join the ring

[0091] For a device to join a ring, some embodiments require the device to sign a request to join the ring and have one of the devices already in the ring approve the request. For example, in some embodiments, when a device meets the ring's requirement to possess a cryptographic secret, the device (i) signs its public key (which has been shared with other devices) and the date / time it was applied to the ring using a private key generated from the cryptographic secret, (ii) encapsulates the signature with its identity for joining the ring, and (iii) signs the identity using its own private key. The signature is then sent to the other devices in the ring as a request to join the ring. When one of the other devices verifies that the requesting device meets all the requirements to join the ring, the established device notifies the other devices in the ring, including the new device that was added. In some embodiments, the notification includes a list of members of the ring, which now includes the new device.

[0092] Figure 11 Conceptually, process 1100 of some embodiments for requesting membership in a ring is illustrated. In some embodiments, when a device determines that it meets all requirements to join a ring, the device (e.g., the device's ring evaluator) performs process 1100. In some embodiments, when a device property changes (e.g., a user adds a password to protect access to the device, a configuration containing encryption keys is installed on the device, a user enters a cloud service account password on the device, etc.) such that the device can now join a ring of which it is not a member, the device performs process 1100 (or a similar process).

[0093] As shown, process 1100 begins by retrieving (at 1105) a device signing key pair. In some embodiments, when the device operating system is initially started and configured by the user of the device, a public / private key pair is randomly generated by the device (and stored on the device). That is, when a user first purchases a device and configures the device for its use (or resets and reconfigures the device's operating system), the device generates a public / private key pair based on randomized seed data. In some embodiments, the seed data of the key pair is not associated with any device hardware, so that if a new key pair is generated for the device (if the user reformats the device), the new key pair will not bear any encryption relationship with the old key pair. In some embodiments, the device uses a device public key shared with other devices belonging to the user (i.e., devices that join the ring together with it) as part of its identity. The device uses its private key to encrypt its stored data items and perform backup recovery (as described in U.S. Provisional Patent Applications 62 / 168,894 and 62 / 172,128 and U.S. Patent Application 14 / 871,498 entitled "Backup System with Multiple Recovery Keys"). Additionally, in some embodiments, the device signs the ring membership request using its private key.

[0094] Next, process 1100 determines (at 1110) whether the ring in which membership is requested uses attestation of secret keys for authentication. That is, some rings require the device requesting membership to indicate that the ring possesses a particular private key (e.g., by signing the membership request) that the established device has a public key.

[0095] When such a key is needed, the process generates (at 1115) (or retrieves, if a key has already been generated) a ring signing key pair based on the ring requirement data. For example, some embodiments require the user to enter a specific password / password in order to join the ring. The device then deterministically generates a key pair from the password, which is used in the ring membership request. In some embodiments, seed data for generating the key pair is provided to the device as part of configuring the device for a specific purpose. For example, if the device is owned by an enterprise and used by its employees, the enterprise can install a configuration specific to its enterprise on the device that includes seed data for generating a public / private key pair, which the device can use to join the enterprise-specific ring. Similarly, application-specific rings can be joined using encrypted data that can be obtained with an application download.

[0096] In addition, the process performs (at 1120) any additional ring credential verification. This may involve self-verification of specific attributes of the device that are required for ring membership but do not require external verification. For example, some embodiments require the device to declare, but not prove in any cryptographic or out-of-band manner, that it runs a specific operating system, is a specific type of device (where device type can be a broad category such as smartphone, smartphone of a specific brand (e.g., Apple, Nokia, HTC, etc.), a specific version of device (e.g., iPhone 5, iPhone 6, etc.), has a password of at least a specific length, etc.

[0097] Additional ring credential verification may also require out-of-band verification (in some embodiments, this is performed after the ring membership request is sent rather than before). Out-of-band verification requires the device to prove, rather than simply declare, the attributes required to obtain ring membership. For example, the device may need to prove through a third party that it is a valid device from a specific manufacturer, that it runs a specific operating system, that its password is at least a specific length, or other attributes.

[0098] Next, the process signs (at 1125) the ring membership request using the device's private key and any private ring signing keys (i.e., any keys generated at operation 1115). This enables the device to prove via its ring membership request that (i) it is who it claims to be, as only it has the private key paired with its shared public key, and (ii) it possesses the cryptographic secrets required to join the ring. In some embodiments, the signed ring membership request also includes other device identifying information, including its public key and the time of the request. Some embodiments of the signed ring request are described below with reference to Figure 13 Describe in more detail.

[0099] Finally, the process sends (at 1130) the signed ring membership request to the other devices already in the ring. In some embodiments, each device associated with the user (e.g., by logging into the user account, by joining a ring that requires the user's password, etc.) stores a list of devices that are members of each possible ring and uses this list to send the ring membership request to the other devices in the ring. As long as one of the devices approves the membership request (e.g., using a password such as Figure 12 The device is added to the ring by following the process shown below.

[0100] Figure 12A process 1200 is conceptually illustrated for determining whether to allow a device to enter a ring in some embodiments. In some embodiments, a first device performs process 1100 (or a similar process) to generate a signed request for ring membership and sends the request to a device that has already been established as a ring member. One (or more) of these established devices then performs process 1200 (or a similar process) to allow the device to enter the ring (assuming the membership request is appropriate) or to deny the request to join the ring.

[0101] As shown, process 1200 begins by receiving (at 1205) a request from another device to join a ring to which the local device (on which process 1200 is currently running) already belongs. In some embodiments, the request is received from the other device wishing to join the ring via a point-to-point connection. The point-to-point connection can be sent via a direct connection (e.g., a Bluetooth connection between devices, etc.) or via a central repository. For example, in some embodiments, the requesting device sends a message to multiple established devices stored in a central repository, and each of these established devices retrieves these requests when active. That is, a locked or turned-off device may not be able to receive requests until it is unlocked, turned on, etc.

[0102] Upon receiving the request, the process determines (at 1210) whether the request has already been approved by another device. In some embodiments, as the requesting device sends a membership request to each established device in the ring, in some cases, one of the established devices will begin processing the request only to determine that one of the other established devices has already added the requesting device to the ring. In some embodiments, when the requesting device is added to the ring, the established device sends a notification to the other established devices and the new device. In this case, process 1200 ends.

[0103] Assuming the requesting device has not yet been added to the ring, the process 1200 determines (at 1215) whether the request correctly identifies the ring. In order to join the ring, some embodiments require the requesting device to generate a request that identifies the members of the ring and / or other aspects of the ring. If the request does not correctly identify the ring, the process ends.

[0104] Next, the process determines (at 1220) whether the requesting device meets all criteria for membership in the ring. As described above, this can include proving possession of a particular cryptographic key by signing the request with a key, asserting attributes of the requesting device (its operating system, device type, etc.), or verifying ring membership requirements out-of-band. Thus, determining whether the requesting device meets all criteria can include initiating an out-of-band process or determining whether an out-of-band process has already been performed to verify the specific criteria of the requesting device. If the requesting device does not meet the criteria, the process ends (and the requesting device is not added to the ring).

[0105] Finally, if the requesting device is otherwise approved for ring membership, the process determines (at 1225) whether the ring requires user approval. This is a specific type of ring criterion because it requires user action to approve the device in order for the requesting device to be admitted to the ring. When user approval is not required, the process proceeds to 1240, described below, to add the requesting device to the ring.

[0106] When the requesting device requires user approval to obtain ring membership, the process displays (at 1230) an approval prompt on the local device (the device executing process 1200). The prompt may simply state that the device is requesting membership to join the ring, or it may provide additional context. For example, the prompt may state the name of the device (e.g., John's iPhone), the device type, the ring name, or other information that may be helpful to the user in evaluating whether the request is valid. The process then waits (not shown) for the user to indicate whether to allow the requesting device to enter the ring.

[0107] Once the user responds to the prompt, process 1200 determines (at 1235) whether the user has approved the requesting device. If the user has not approved the requesting device, the process ends. However, if the user approves the requesting device, the process adds the requesting device to the ring (at 1240). In some embodiments, the established device (performing process 1200) adds the requesting device to the ring by sending a message containing a list of all members of the ring to all members of the ring, including the requesting device. Some embodiments sign this message with the sending device's private key.

[0108] Figure 13A first device 1300 is conceptually shown requesting to join a ring and being approved by a second device 1325, proceeding through four stages 1305 through 1320. The first device 1300 can be any type of electronic device capable of joining a ring, such as a smartphone, smartwatch, tablet, laptop, or desktop computer. Regarding the first device 1300, the diagram shows that the first device 1300 includes a first storage device 1330, which stores information about the various rings in which a group of devices (including the first device (D1) 1300) participate. As shown in the first stage 1305, these rings include a first ring with D2 and D3 as members, a second ring with all three devices as members, and a third ring with D2 as its sole member. The first device 1300 also includes a second storage device 1335, which stores various keys related to other devices and / or rings. These keys include a public / private key pair for the device 1300 itself, as well as public keys for D2 and D3.

[0109] In the first stage 1305, the enterprise configuration file 1340 is installed on the first device 1300. As shown in the second stage 1310, the enterprise configuration file 1340 includes the enterprise key pair (or seed data used to generate the enterprise key pair) stored in the key storage device 1335. The enterprise configuration file 1340 may also include application installation on the device 1300, various security measures, etc.

[0110] In the third stage 1315, the ring evaluator 1345 of the device 1300 determines that the device now possesses the necessary credentials (i.e., the enterprise private key) to join the first ring. Therefore, the ring evaluator generates a request using the request signer 1350. In some embodiments, the request signer is a cryptographic digital signature generation function that uses a private key to sign a message or other data. The first device D1 1300 then sends the request 1355 to the second device D2 1325. Although not shown, in some embodiments, the first device 1300 also sends the request to D3.

[0111] In some embodiments, the request 1355 is made by the first device 1300 using a process such as Figure 11The process shown is used to generate. Specifically, in some embodiments, device 1300 (i) uses a private key generated from a cryptographic secret to sign its public key (already shared with other devices) and the date / time of the application for the ring, (ii) encapsulates this signature with the identity used to join the ring, and (iii) uses its own private key to sign the identity. As shown in the figure, the innermost part of the request 1355 includes the public key of the device and the time of the first device's application for the ring. The ring-specific private key (i.e., the enterprise key received by device 1300 as part of the enterprise profile) is then used to sign this set of data (public key + application time). The device identity (also known as peer information) includes this signature and other data about the device (e.g., its name, hardware-specific identifiers and / or other data). The private key of device 1300 is then used to sign the device identity, thereby confirming that the request actually came from the first device.

[0112] In the fourth stage 1320, the second device 1325 receives the request 1355 and verifies the request. The second device 1325 uses a signature verifier 1360, which uses the public key of the first device (previously shared) and the enterprise public key (the device is already in the enterprise ring and therefore stores the enterprise key pair). If the signature verifier 1360 verifies that the request is correctly signed by the first device, the ring evaluator 1365 on the second device 1325 adds the first device 1300 to the first ring. Although not shown in this figure, the second device 1325 sends a message to both D1 and D3 indicating that all three devices are members of the first ring. In some embodiments, the message is signed by the second device 1325.

[0113] Depend on Figure 13 The first device in a ring to join only needs to prove possession of the signature on the enterprise ring key request. However, as mentioned above, in some cases, the ring may also have additional requirements. Figure 14 The same device 1300 is conceptually shown joining a third ring through five stages 1405 to 1425, which require verification of device attributes by a central authority and possession of a secret encryption key. In the first stage 1405, the device 1300 receives (e.g., via user input, download, etc.) an encryption secret 1430 for the third ring. Thus, the second stage 1410 shows that the key storage on the first device 1300 includes a public / private key pair generated from the encryption secret 1430.

[0114] In the third phase, first device 1300 sends a signed request 1435 to connect the first ring to second device 1325. In this case, the first device only sends this request to the second device because it is the only device currently a member of the ring. In some embodiments, request 1435 is signed in the same manner as request 1355 shown in the previous figure. That is, the request includes the time the request to the first ring is made and the public key of the first device, and is signed using a private key generated from encrypted secret 1430. This information is then packaged with the device identity and signed using the private key of device 1300.

[0115] In the fourth stage, the second device 1325 receives a verification 1440 of the attributes of the first device 1300 before accepting the first device into the first ring. In this case, the devices use a central authority 1445 to verify the device attributes via a process that can be initiated by either device. The central authority 1445 can be a device manufacturer that verifies that the device is trustworthy or that the device has a specific operating system. As described above, in various embodiments, the out-of-band process can involve user action rather than a central authority, or involve the direct exchange of information between the two devices. Finally, in the fifth stage 1425, the second device 1325 verifies the request and adds the first device 1300 to the first ring, as shown in the previous figure.

[0116] IV. Synchronization Process

[0117] Once devices have been established in rings (subgroups for verification), they can be arranged into views (subgroups for synchronization). As mentioned, in some embodiments, rings are used to organize devices into views, and views are used to determine which data items stored on a device should be synchronized with other devices. In some embodiments, a view is defined by: (i) a set of requirements for devices that participate in the view, and (ii) a class of data items that are synchronized between devices that participate in the view. In some embodiments, the set of requirements for a view is membership in one or more rings (as described above with reference to Figure 7-Figure 9 shown).

[0118] The view is used to enable a group of related devices to synchronize data items with each other. In various embodiments, these synchronized data items include usernames and passwords for online accounts (e.g., financial services websites, online forum websites, media content providers, online retail websites, etc.), encryption keys and / or secrets (i.e., data that can be used to generate keys), application-specific service keys that allow access to application-related data stored on a central server, network (e.g., Wi-Fi network) passwords, notes, photos, documents, and other files, etc.

[0119] Figure 15 Conceptually, a process 1500 is shown for synchronizing key chain data from a first device to a second device in some embodiments. In this case, the process performs the synchronization process on a specific secure channel between the first and second devices, which can be the only secure channel between the devices or one of several secure channels between the devices. While the process performs synchronization on all views over a specific secure channel, other embodiments may use a process that performs synchronization on all devices (simultaneously) for a specific view or all views of a specific device (regardless of the channel).

[0120] As shown, process 1500 begins by receiving (at 1505) a command to synchronize data of a particular remote device over a particular channel. In some embodiments, the process is performed on a first device that participates in at least one view with a second remote device. The first device can synchronize data items with the second device periodically, can synchronize data items based on a user command, or can synchronize data items whenever the first device receives a new data item and determines (based on a set of views to which the data item belongs) that the data item should be synchronized with the second device.

[0121] In some embodiments, each pair of devices in the entire device group creates a secure channel between themselves for synchronizing data items (e.g., using an off-the-record (OTR) instant messaging protocol). In some embodiments, the first device transmits the identified synchronized data items for all views in which the two devices participate to the second device via the secure channel, as long as the view does not impose any additional requirements on the secure channel. When the view imposes additional requirements on the secure channel (e.g., encrypting the data items using an encryption key required to obtain authentication membership in a subgroup), the first device can use multiple different secure channels to synchronize the set of data items with the second device. In this case, in some embodiments, process 1500 is performed separately for each channel.

[0122] The process next identifies (at 1510) a set of views in which both devices (the local device performing the synchronization and the device whose data is being synchronized) participate. In some embodiments, a view evaluator module in the device generates a set of views in which the remote device participates based on the rings of which the remote device is a member. As described above, each device keeps track of the rings of which each other device in the group is a member so that this data can be used to determine the views. Similarly, the device knows which views it participates in based on its own ring membership.

[0123] Process 1500 identifies (at 1515) a new synchronized data item that is tagged by any view in the identified group (a view in which both devices participate) and that has not been previously synchronized to the remote device. The device only synchronizes data that is part of its keychain (i.e., data belonging to views in which it is a member) and data belonging to at least one view in which the remote device participates. When a new data item is received by the first device (e.g., from a user entering a new password, importing or downloading a new photo, etc.) to be added to the set of synchronized data items, the device in some embodiments dynamically tags the data as belonging to one or more views. For example, the data may be tagged based on the application in which the data was created (e.g., Wi-Fi network / password vs. online account username / password), the type of website accessible by the username / account (e.g., financial website vs. non-financial website), whether the data is related to a business, etc. When synchronizing data items with a remote device, the first device identifies all synchronized data items it stores that have not yet been transferred to the second device (and that belong to views in which the second device participates).

[0124] In the event that data items are identified, the process 1500 decrypts these new data items as they are stored on the local device (at 1520). In some embodiments, the decryption process uses the local device's private key, which is known only to the device. In some embodiments, the data items are stored on the device in an encrypted form encrypted using the device's public key. Some embodiments also encrypt the data items for storage on the device using one or more additional keys, such as a public key from a key pair used to join the ring (e.g., a key pair based on a user password, an enterprise key pair, etc.). For each public key used to encrypt a data item for storage on the device, the process decrypts the data item using the corresponding private key.

[0125] Next, the process encrypts (at 1525) the data items for transmission to the remote device in accordance with the requirements of the secure channel over which the data items are transmitted. As mentioned, some embodiments use a password-authenticated key exchange (PAKE), which relies on a shared secret key for encrypting messages between devices. In some cases, view requirements for a particular view may impose additional restrictions on the secure channel used to synchronize data items belonging to that particular view, such as the use of additional keys (e.g., requiring possession of a certain key to join a ring, membership requirements for a particular view). Thus, some embodiments use at least the shared secret key and possibly additional keys to encrypt the data items.

[0126] Finally, the process sends (at 1530) the encrypted items of the view to the remote device over a secure channel between the devices. In various embodiments, the secure channel may pass through a centralized service that allows temporary storage even when the receiving device is unlocked (e.g., a memory for a cloud service account to which both devices are logged). However, in some embodiments, the use of a secure channel protects these communications from man-in-the-middle attacks. Other embodiments use a direct peer-to-peer connection (e.g., via a Bluetooth connection). Upon receiving the encrypted items, in some embodiments, the remote device decrypts the items (as encrypted on the channel) and re-encrypts them using its own public key for local storage. In some embodiments, the remote device also performs a process similar to process 1500 to synchronize any of its new data items with the local device.

[0127] Figure 16 17 conceptually illustrates a pair of devices 1600 and 1650 that synchronize data with each other. Specifically, Figure 16 The diagram shows the acceptance of new data items for synchronization by a first device 1600, through two stages 1605 and 1610. The first stage 1605 shows the items stored by each of two devices 1600 and 1650. In this example, the first device 1600 participates in views V1 and V2, while the second device 1650 participates in views V1 and V3. As shown, the first device stores Item 1 1615, Item 2 1620, and Item 3 1625. The first two items, 1615 and 1620, belong to the first view V1, while the third item 1625 belongs to the second view V3, and these items are labeled accordingly. The second device stores Item 1 1615, Item 2 1620, and Item 4 1630. The fourth item 1630 belongs to V3, which is why it is stored only on the second device 1650. Finally, this stage shows a legend indicating the notation used in this and subsequent figures, which indicates that data items are encrypted using different keys. Items stored on the first device 1600 are encrypted with the first device's key, while items stored on the second device 1650 are encrypted with the second device's key.

[0128] In the second stage, the user of first device 1600 (who is also the user of second device 1650, and thus the devices synchronize data with each other) provides data item 51635 to the device via application 1640. The application might be a web browser application through which the user enters a password, a third-party application that uses passwords, an application through which the user creates new files (e.g., documents via a word processing application, images captured via a camera application, etc.), or other application through which device 1600 receives data.

[0129] This fifth data item 1635 is sent to a data tagger 1645 on the first device 1600, which identifies the data item as belonging to the first view V1 and tags the item as such. This may be due to the application 1640 through which the item was received or other data identifying the data item (its file type, the web domain associated with it, etc.). The item is also sent to an encryption function 1655 (e.g., which performs asymmetric encryption such as RSA, DSS, elliptic curve cryptography, etc.). The encryption function 1655 encrypts the data item 1635 using the public key of the first device (not shown) for storage. In some embodiments, as shown in the figure, the view information is not encrypted because the information is not sensitive and does not need to be decrypted in order for the device to access the view data.

[0130] Figure 17 The synchronization of a new data item 1635 from a first device 1600 to a second device 1650 is shown through three stages 1705 to 1715. As shown in the first stage 1705, the view evaluator module 1720 on the first device 1600 notifies the synchronization engine 1725 to synchronize data with the second device. The device-to-view mapping indicates that V1 is the only view in which both devices participate, so only data items marked as belonging to V1 should be synchronized between the devices.

[0131] Thus, in the second phase 1710, the first device 1600 sends a new data item 1635 to the second device 1650. As shown by the varying dashed and dotted lines in the representation of the new data item 1635, the first device decrypts the stored data item using its own private key (and potentially any other keys as needed) and then encrypts the plaintext version of the data item using the shared key used for the secure channel between the devices. The sync engine 1725 on the first device 1600 then sends the encrypted data item 1635 over the secure channel, where it is received by the sync engine 1730 on the second device 1650. In some embodiments, as a requirement of the secure channel, the view tag on the data item 1635 is also encrypted using the shared key. As mentioned, although shown as a direct connection between the two devices 1600 and 1650, in some embodiments, the data item 1635 is sent by the first device 1600 to a central repository (e.g., cloud storage) and subsequently retrieved from the repository by the second device 1650.

[0132] The third stage 1715 shows the second device 1650 storing the data item 1635. After receiving the data item, the device 1650 decrypts the item using the shared key of the secure channel (and any other keys as necessary, depending on the channel requirements for V1), and then encrypts the key for storage using its own public key (and possibly additional encryption keys).

[0133] As mentioned, synchronized data items can include a variety of different types of items in different embodiments, including password / username combinations, Wi-Fi networks and corresponding passwords, encryption keys, files, etc. In some embodiments, the data items include application-specific keys that enable access to application-related data stored in the cloud service via a hierarchy of nested keys. That is, for each application on the device (or each of a subgroup of applications on the device), the synchronized data includes an application-specific private key (e.g., a photo application key).

[0134] Application-specific private keys are used to access data stored in a tree of key and data fields, which ultimately allow access to the application data itself. Figure 18 and Figure 19 Shown in. Figure 18 A container structure 1800 is shown that is stored in a central repository (e.g., cloud storage) and, in some embodiments, is available for download to a device. The container structure 1800 includes its own private key 1805 (or seed data for generating the private key) encrypted using an application-specific public key. Therefore, accessing this container private key requires possession of the application-specific private key synchronized as a keychain data item. The container structure 1800, which represents a high-level overview of the application, includes a set of unencrypted fields 1810 (Field_1 through Field_M) that do not require access to any key, and a set of fields 1815 (Field_M+1 through Field_N), each of which is encrypted using the container public key 1805 (thus requiring possession of the container private key to access).

[0135] In addition, the container public key is used to encrypt the zone private key 1905 that is part of the zone structure 1900. Therefore, accessing the zone structure requires access to the container private key 1805, which in turn requires access to the application-specific service key. Like the container structure 1800, the zone structure 1900 includes several unencrypted fields 1910 (field_1 through field_Q) and several fields 1915 (field_Q+1 through field_R) that are encrypted using the zone key. While the container represents a high-level overview of the application, in some embodiments, a zone represents a specific database or table within the container. For example, a zone could represent a set of photos associated with the application, with each photo represented by a record (and the record to which the zone points).

[0136] In some embodiments, each record referenced by a zone may include the key required to access specific application data (e.g., a specific photo). In some embodiments, each record has a key encrypted with its zone public key, and therefore requires the zone private key to access. Records are structured similarly to containers and zones, with unencrypted fields and encrypted fields. For example, fields for a photo record may store the photo's title, location, timestamp, etc., as well as the key that actually unlocks the photo. In some embodiments, the record key unlocked by the zone key is a symmetric key, rather than the private key in a public / private key pair.

[0137] In addition to sharing via a synchronization process, in some embodiments, application-specific keychain data items may be recovered via a secure escrow system, as described in U.S. Provisional Patent Applications 62 / 168,894 and 62 / 172,128, U.S. Patent Application 14 / 871,498, and U.S. Patent Publication 2014 / 0093084.

[0138] V. Dynamic Changes in Group Membership

[0139] like Figure 2-6 As shown, in some embodiments, a device can be a member of multiple rings. In addition, the device can be dynamically moved in and out of these rings as the device's properties change, causing the device to meet the requirements of various rings or no longer meet the requirements. When the device's properties change (e.g., a configuration file containing a specific encrypted secret is installed on the device, the user changes the device's password length or adds a password to the device, etc.) so that the device becomes eligible to join a ring, the device generates and sends a request for membership of the ring, as described above. On the other hand, when the device's properties change so that the device no longer meets the membership requirements of a ring of which the device is currently a member, the device detects that it should no longer be a member of the ring and transmits this notification to the other devices that are members of the ring.

[0140] A device joining or leaving a ring may also affect the device's participation in one or more views. For example, when a device joins a ring, the device may now be able to participate in a new view and should therefore receive data belonging to the new view (via a synchronization process). On the other hand, when a device leaves a ring, the device may no longer be allowed to participate in one or more views that require membership of the particular ring of which the device is no longer a member. This will be recognized by other devices associated with that particular device, which will no longer share data belonging to these affected views with that particular device. Additionally, in some embodiments, that particular device will delete all data items that it is no longer authorized to access. In other embodiments, in the event that the user wants to retain data on the device even if the device will no longer receive new data for that view, the device will ask the user before deleting any data.

[0141] Figure 20 A process 2000 is conceptually illustrated for some embodiments of dynamically modifying a device's ring membership and subsequent view participation. In some embodiments, process 2000 is performed by a device to evaluate its own ring membership and then evaluate its view participation. As described above, the device can be a smartphone, smartwatch, tablet, laptop, desktop computer, or any other device that participates in a synchronization system between related devices.

[0142] As shown, process 2000 begins by identifying (at 2005) a change in the device configuration (of the device on which the process is running). Such a change in the device configuration may be the result of a user changing the device password (e.g., changing from a four-digit password to a long password or vice versa; removing a password from use on the device; adding a password device, etc.), installing an application on the device, upgrading the device's operating system, modifying an application or device settings, learning a new cryptographic secret, etc. Some embodiments periodically check for changes relative to the enumerated set of ring requirements, while in some embodiments, process 2000 is event-driven in that certain changes to the device will cause certain operations of process 2000 to be performed.

[0143] The process determines (at 2010) whether the change results in any increase in ring members. Figure 2-Figure 6 For rings 200, 300, 400, 500, and 600 in FIG, examples of such changes would be if a user changed the password on smartphone 110 or watch 115 to have at least twelve characters instead of four, if an enterprise configuration was installed on those devices or on home desktop computer 130, if a device password was added to streaming video set-top box 125, etc. As described above, many other types of changes may also cause a device to become eligible for membership in a ring.

[0144] When a change to the device configuration results in eligibility for membership in at least one ring, the process generates (at 2015) a request to join the ring and sends the signed request to the other devices in the ring. In some embodiments, the device performs Figure 11 Process 1100 may be performed to generate and send a signed ring at 2015. Once the device has successfully joined the ring (assuming the membership request is valid), if the ring membership results in the device participating in one or more additional views, process 1500 or a similar process may be performed by one of the other devices to synchronize data items belonging to those additional views with the device.

[0145] The process also determines (at 2020) whether the change results in the device being removed from any ring. Figure 2-Figure 7 Examples of such changes would be removing the enterprise configuration from the smartphone 105 or laptop 120, removing the password from any of the devices 105 to 120 or 130, shortening the password on the smartphone 105, laptop 120, or desktop computer 130, etc. Many other types of changes (e.g., revoking a password or encryption key from a device) may also cause the device to lose ring membership.

[0146] If no device configuration changes have resulted in the device being removed from any ring, process 2000 ends. Otherwise, the process notifies (at 2025) the other devices in the ring that the device has been removed from the ring. Some embodiments send a message signed with the device's private key to indicate the change. In addition to notifying the other devices in the ring, some embodiments also notify any other related devices that are not in that particular ring (e.g., other devices of the same user). For example, if smartphone 105 is removed from ring 500 (because the enterprise configuration was removed from the device), in some embodiments it will notify all devices 110 to 130.

[0147] In addition to determining whether a device change affects the device's ring state, process 2000 also handles potential view participation changes for the device if the device leaves a ring. Thus, the process determines (at 2030) whether a ring membership removal results in removal from any view. Because participation in any particular view is determined based on membership in one or more rings, removal from one of the rings used to determine view participation will result in the device no longer being eligible to participate in that view. For example, using the example from the previous paragraph, removal of smartphone 105 from ring 500 will subsequently result in the smartphone no longer being eligible to participate in second view 800.

[0148] When a device is removed from a view, there is no need to notify other devices participating in the view, as the other devices will reach the same conclusion based on the device's removal from one of the required rings. However, in some embodiments, process 2000 deletes (at 2035) any synchronized data items that no longer belong to any view in which the device participates. As described above, some embodiments do not automatically delete the data, but instead prompt the user to ask whether the data should be deleted (so that the user does not lose any data they do not want to lose). In some embodiments, whether the user is prompted depends on the view. For example, if an enterprise view requires a certain level of security, then if the device no longer meets the security constraints, the enterprise may not want to provide the user with the option of retaining the data. However, such views may provide the user with an option to reverse the changes that resulted in removal from the view (e.g., reversing the change to a shorter password).

[0149] Figures 21A to 21B Shown Figure 16 and Figure 17 The password of one of the devices 1600 and 1650 has been changed, causing them to be removed from the ring through four stages 2105 to 2120. As shown in the first stage 2105, the second device 1650 stores the synchronized data items 1615, 1620, and 1635 belonging to view V1 and the data item 1630 belonging to view V3. At this stage, the user of the device 1650 changes his password from the 12-digit password ("012345678910") to the 4-digit password "1234".

[0150] Thus, in the second stage 2110, the ring evaluator 2125 of the second device 1650 identifies that the device should no longer be a member of the ring (Ring 3) because its password is no longer long enough. Therefore, the second device 1650 sends a message 2130 to the first device 1600, notifying the first device that the second device is no longer a member of Ring 3. In some embodiments, as shown, the message indicates the reason for the ring state change, although other embodiments simply send a notification without additional data.

[0151] In the third phase, both the first device 1600 and the second device 1650 process the removal of the second device from ring 3. The ring evaluator 2135 on the first device notices the removal of the second device from the ring and also notifies the view evaluator 1720 of this change in ring state so that the view evaluator can determine for future synchronization operations that the view state of the second device has completely changed. On the second device, the ring evaluator 2125 notifies the view evaluator 2140 of the same change, and the view evaluator thereby recognizes that the second device 1650 is no longer participating in view V1 (i.e., because ring 3 membership is a requirement for view V1).

[0152] Therefore, view evaluator 2140 removes data items 1615, 1620, and 1635 from the second device because they belong to view V1 which the device no longer participates in. The fourth stage 2140 shows the result, where second device 1650 only stores item 1630 (which belongs to view V3).

[0153] VI. Electronic Systems

[0154] Many of the features and applications described above can be implemented as a software process designated as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium). When these instructions are executed by one or more computing or processing units (e.g., one or more processors, the cores of a processor, or other processing units), these instructions enable one or more processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, random access memory (RAM) chips, hard drives, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), and the like. Computer-readable media do not include carrier waves and electrical signals transmitted wirelessly or via wired connections.

[0155] In this specification, the term "software" is intended to include firmware residing in a read-only memory or an application stored in a magnetic storage device, which can be read into a memory for processing by a processor. Additionally, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while retaining different software inventions. In some embodiments, multiple software inventions can also be implemented as stand-alone programs. Finally, any combination of separate programs that together implement the software inventions described herein is within the scope of the present invention. In some embodiments, when installed to run on one or more electronic systems, a software program defines one or more specific machine implementations that execute and enforce the software program operations.

[0156] A.Mobile devices

[0157] Some embodiments of user data sharing are performed on mobile devices such as smartphones (e.g. ) and tablets (e.g. ) occurs on. Figure 22 2200 is an example of the architecture of such a mobile computing device. As shown, the mobile computing device 2200 includes one or more processing units 2205, a memory interface 2210, and a peripheral device interface 2215.

[0158] The peripheral device interface 2215 is coupled to various sensors and subsystems, including a camera subsystem 2220, one or more wired communication subsystems 2223, one or more wireless communication subsystems 2225, an audio subsystem 2230, an I / O subsystem 2235, etc. The peripheral device interface 2215 enables communication between the processing unit 2205 and various peripheral devices. For example, an orientation sensor 2245 (e.g., a gyroscope) and an acceleration sensor 2250 (e.g., an accelerometer) are coupled to the peripheral device interface 2215 to facilitate orientation and acceleration functions.

[0159] The camera subsystem 2220 is coupled to one or more optical sensors 2240 (e.g., a charge coupled device (CCD) optical sensor, a complementary metal oxide semiconductor (CMOS) optical sensor, etc.). The camera subsystem 2220 coupled to the optical sensor 2240 facilitates camera functions, such as image and / or video data capture. The wired communication subsystem 2223 and the wireless communication subsystem 2225 are used to facilitate communication functions.

[0160] In some embodiments, the wireless communication subsystem 2225 includes a radio frequency receiver and transmitter, and an optical receiver and transmitter ( Figure 22 (not shown). These receivers and transmitters of some embodiments are implemented to operate over one or more communication networks, such as a GSM network, a Wi-Fi network, a Bluetooth network, etc. The audio subsystem 2230 is coupled to a speaker to output audio (e.g., to output voice navigation instructions). Additionally, in some embodiments, the audio subsystem 2230 is coupled to a microphone to facilitate voice-enabled functionality.

[0161] The I / O subsystem 2235 is concerned with transmissions between input / output peripherals (such as a display, touch screen, etc.) and the data bus of the processing unit 2205 via the peripheral device interface 2215. The I / O subsystem 2235 includes a touch screen controller 2255 and other input controllers 2260 to facilitate transmissions between the input / output peripherals and the data bus of the processing unit 2205. As shown, the touch screen controller 2255 is coupled to the touch screen 2265. The touch screen controller 2255 uses any of a variety of touch-sensitive technologies to detect contact and movement on the touch screen 2265. The other input controllers 2260 are coupled to other input / control devices, such as one or more buttons. Some embodiments include a near-touch screen and a corresponding controller that can detect near-touch interactions in place of or in addition to touch interactions.

[0162] The memory interface 2210 is coupled to the memory 2270. In some embodiments, the memory 2270 includes volatile memory (e.g., high-speed random access memory), non-volatile memory (e.g., flash memory), a combination of volatile and non-volatile memory, and / or any other type of memory. Figure 22 As shown in FIG, the memory 2270 stores an operating system (OS) 2271. The OS 2271 includes instructions for processing basic system services and for executing hardware-related tasks.

[0163] The memory 2270 also includes: communication instructions 2274 that facilitate communication with one or more additional devices (e.g., for peer-to-peer data sharing, or for connecting to a server via the Internet for cloud-based data sharing); graphical user interface instructions 2276 that facilitate graphical user interface processing; image processing instructions 2278 that facilitate image-related processing and functions; input processing instructions 2280 that facilitate input-related (e.g., touch input) processes and functions; audio processing instructions 2282 that facilitate audio-related processes and functions; and camera instructions 2284 that facilitate camera-related processes and functions. The above instructions are merely exemplary, and in some embodiments, the memory 2270 includes additional and / or other instructions. For example, the memory for a smartphone may include telephony instructions that facilitate telephony-related processes and functions. The instructions identified above need not be implemented as separate software programs or modules. The various functions of the mobile computing device may be implemented in hardware and / or software, including in one or more signal processing and / or application-specific integrated circuits.

[0164] Although Figure 22 The components illustrated in the drawings are shown as separate components, but one of ordinary skill in the art will recognize that two or more components may be integrated into one or more integrated circuits. In addition, two or more components may be coupled together by one or more communication buses or signal lines. In addition, although many functions have been described as being performed by one component, one of ordinary skill in the art will recognize that the components may be integrated into one or more integrated circuits. Figure 22 The functionality is split across two or more integrated circuits.

[0165] B.Computer system

[0166] Figure 23Another example of an electronic system 2300 that may be used to implement some embodiments of the present invention is conceptually illustrated. The electronic system 2300 may be a computer (e.g., a desktop computer, a personal computer, a tablet computer, etc.), a phone, a PDA, or any other type of electronic or computing device. Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 2300 includes a bus 2305, one or more processing units 2310, a graphics processing unit (GPU) 2315, a system memory 2320, a network 2325, a read-only memory 2330, a permanent storage device 2335, an input device 2340, and an output device 2345.

[0167] Bus 2305 generally represents all system, peripheral, and chipset buses that communicatively connect the many internal devices of electronic system 2300. For example, bus 2305 may communicatively connect one or more processing units 2310 with read-only memory 2330, GPU 2315, system memory 2320, and permanent storage device 2335.

[0168] The processing unit 2310 retrieves instructions to be executed and data to be processed from these various memory units in order to perform the processes of the present invention. In different embodiments, one or more processing units may be a single processor or a multi-core processor. Some instructions are transmitted to the GPU 2315 and executed by the GPU. The GPU 2315 can offload various computational instructions or supplement the image processing provided by the one or more processing units 2310. In some embodiments, the kernel shading language of CoreImage can be used to provide such functionality.

[0169] Read-only memory (ROM) 2330 stores static data and instructions required by one or more processing units 2310 and other modules of the electronic system. Permanent storage device 2335, on the other hand, is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 2300 is turned off. Some embodiments of the present invention use mass storage devices (such as magnetic or optical disks and their corresponding hard drives, integrated flash memory) as permanent storage device 2335.

[0170] Other embodiments use removable storage devices (such as floppy disks, flash memory devices, and their corresponding drives) as permanent storage devices. Like permanent storage device 2335, system memory 2320 is also a read-write memory device. However, unlike storage device 2335, system memory 2320 is a volatile read-write memory, such as random access memory. System memory 2320 stores some of the instructions and data required by the processor during operation. In some embodiments, the processes of the present invention are stored in system memory 2320, permanent storage device 2335, and / or read-only memory 2330. For example, various memory units include instructions for processing multimedia clips according to some embodiments. One or more processing units 2310 retrieve instructions to be executed and data to be processed from these various memory units in order to perform the processes of some embodiments.

[0171] Bus 2305 is also connected to input device 2340 and output device 2345. Input device 2340 enables the user to convey information to the electronic system and select the command to the electronic system. Input device 2340 includes an alphanumeric keyboard and an indicating device (also referred to as "cursor control device"), a camera (e.g., a webcam), a microphone or similar devices for receiving voice commands, etc. Output device 2345 displays images or other output data generated by the electronic system. Output device 2345 includes a printer and a display device such as a cathode ray tube (CRT) or a liquid crystal display (LCD), and a loud speaker or similar audio output device. Some embodiments include devices such as a touch screen that serve as both input device and output device.

[0172] Finally, if Figure 23 As shown in FIG, bus 2305 also couples electronic system 2300 to a network 2325 via a network adapter (not shown). In this way, the computer can be part of a network of computers, such as a local area network ("LAN"), a wide area network ("WAN"), or an intranet, or can be part of a network of networks, such as the Internet. Any or all components of electronic system 2300 can be used with the present invention.

[0173] Some embodiments include electronic components, such as microprocessors, storage devices, and memories, that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as a computer-readable storage medium, a machine-readable medium, or a machine-readable storage medium). Some examples of such computer-readable media include RAM, ROM, compact disc-read only (CD-ROM), compact disc-recordable (CD-R), compact disc-rewritable (CD-RW), digital versatile disc-read only (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini-SD card, micro-SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable A computer readable medium may store a computer program that is executable by at least one processing unit and includes a set of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as that produced by a compiler, and files including higher-level code that can be executed by a computer, electronic component, or microprocessor using an interpreter.

[0174] While the above discussion primarily relates to microprocessors or multi-core processors executing software, some embodiments are implemented by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuits themselves. Additionally, some embodiments execute software stored in programmable logic devices (PLDs), ROM, or RAM devices.

[0175] As used in this specification and any claims of this patent application, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical devices. These terms exclude persons or groups of persons. For the purposes of this specification, the terms display or displaying mean displaying on an electronic device. As used in this specification and any claims of this patent application, the terms "computer-readable medium" and "machine-readable medium" are entirely limited to tangible, physical objects that store information in a form that can be read by a computer. These terms exclude any wireless signals, wired download signals, and any other transient signals.

[0176] Although the present invention has been described with reference to numerous specific details, one skilled in the art will recognize that the present invention may be embodied in other specific forms without departing from the spirit of the invention. For example, the various drawings (including Figure 11 、 Figure 12 、 Figure 15 and Figure 20 ) conceptually illustrates the process. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in a continuous series of operations, and different specific operations may be performed in different embodiments. In addition, the process can be implemented using several sub-processes or as a larger macro-process. Therefore, it will be understood by those skilled in the art that the present invention is not limited by the foregoing illustrative details, but is defined by the appended claims.

Claims

1. A method for synchronizing a set of data items with a second device, the method comprising, at a first device: receiving a request to synchronize the set of data items stored on the first device with the second device; identifying one or more synchronization subgroups in which both the first device and the second device participate, wherein participation in at least one of the one or more synchronization subgroups is defined based on membership in at least one authentication subgroup; identifying the set of data items on the first device that are marked as included in the one or more synchronization subgroups and that have not been previously synchronized to the second device; decrypting the set of data items using one or more private keys; encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device; and The encrypted set of data items is sent to the second device via the secure channel.

2. The method according to claim 1, further comprising: An off-the-record (OTR) instant messaging protocol is utilized to create the secure channel with the second device.

3. The method according to claim 1, further comprising: Receiving, by the first device, a data item from the set of data items; identifying to which synchronization subgroups of the one or more synchronization subgroups the data item belongs; as well as The data item is marked as belonging to the identified one or more synchronization subgroups.

4. The method of claim 3 , wherein identifying which of the one or more synchronization subgroups the data item belongs to further comprises identifying a source application through which the data item was received, a file type, a web domain with which the data item is associated, or some combination thereof.

5. The method according to claim 1, further comprising: Receiving, by the first device, a data item from the set of data items; as well as The data item is encrypted using the public key of the first device to store the encrypted data item on the first device.

6. The method of claim 1 , wherein encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device further comprises using a shared key used to encrypt messages of the secure channel between the first device and the second device.

7. The method of claim 6, wherein encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device further comprises using an additional key that a device needs to possess in order to join the one or more synchronization subgroups.

8. The method of claim 1 , wherein decrypting the set of data items using one or more private keys further comprises using a private key of the first device, a public key of a key pair used to join the at least one verification subgroup, or some combination thereof.

9. A first device configured to synchronize a set of data items with a second device, the first device comprising: means for receiving a request to synchronize the set of data items stored on the first device with the second device; means for identifying one or more synchronization subgroups in which both the first device and the second device participate, wherein participation in at least one of the one or more synchronization subgroups is defined based on membership in at least one authentication subgroup; means for identifying the set of data items on the first device that are marked as included in the one or more synchronization subgroups and that have not been previously synchronized to the second device; means for decrypting the set of data items using one or more private keys; means for encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device; and means for sending the encrypted set of data items to the second device via the secure channel.

10. The first device according to claim 9, further comprising: Means for establishing the secure channel with the second device using an off-the-shelf (OTR) instant messaging protocol.

11. The first device according to claim 9, further comprising: means for receiving, by the first device, a data item from the set of data items; means for identifying to which of the one or more synchronization subgroups said data item belongs; as well as Means for marking the data item as belonging to the identified one or more synchronization subgroups.

12. A first device according to claim 11, wherein the means for identifying which of the one or more synchronization subgroups the data item belongs to further comprises means for identifying a source application through which the data item is received, a file type, a web domain with which the data item is associated, or some combination thereof.

13. A first device according to claim 9, wherein the means for encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device further comprises means for using a shared key for encrypting messages of the secure channel between the first device and the second device.

14. A first device according to claim 13, wherein the means for encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device further comprises means for using an additional key that a device needs to possess in order to join the one or more synchronization subgroups.

15. A first device according to claim 9, wherein the means for decrypting the set of data items using one or more private keys further comprises means for using a private key of the first device, a public key of a key pair for joining the at least one verification subgroup, or some combination thereof.

16. A first device configured to synchronize a set of data items with a second device, comprising: at least one processor; and at least one non-transitory computer-readable storage medium storing instructions that, when executed by the at least one processor, cause the first device to synchronize a set of data items with the second device by performing steps comprising: receiving a request to synchronize the set of data items stored on the first device with the second device; identifying one or more synchronization subgroups in which both the first device and the second device participate, wherein participation in at least one of the one or more synchronization subgroups is defined based on membership in at least one authentication subgroup; identifying the set of data items on the first device that are marked as included in the one or more synchronization subgroups and that have not been previously synchronized to the second device; decrypting the set of data items using one or more private keys; encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device; and The encrypted set of data items is sent to the second device via the secure channel.

17. The first device according to claim 16, wherein the steps further comprise: Receiving, by the first device, a data item from the set of data items; as well as The data item is encrypted using the public key of the first device to store the encrypted data item on the first device.

18. The first device of claim 16, wherein encrypting the set of data items in accordance with the requirements of the secure channel via which the set of data items are to be transmitted to the second device further comprises the step of using a shared key for encrypting messages of the secure channel between the first device and the second device.

19. A first device according to claim 18, wherein encrypting the set of data items according to the requirements of the secure channel via which the set of data items are to be transmitted to the second device further comprises the step of using an additional key that a device needs to possess in order to join the one or more synchronization subgroups.

20. The first device of claim 16, wherein decrypting the set of data items using one or more private keys further comprises the step of using a private key of the first device, a public key of a key pair used to join the at least one verification subgroup, or some combination thereof.

Images