Patent Publication Number: US-10789386-B2

Title: Dispatching identity information from secure hardware appliance

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
     This application is a continuation-in-part of U.S. application Ser. No. 15/347,551, filed Nov. 9, 2016. This application also claims the benefit of U.S. Provisional Application No. 62/469,322, filed Mar. 9, 2017. The contents and teachings of both prior applications are incorporated herein by reference in their entirety. 
    
    
     STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
     Not Applicable. 
     NAMES OF PARTIES TO A JOINT RESEARCH AGREEMENT 
     Not Applicable 
     BACKGROUND 
     1. Field of the Invention 
     This invention relates generally to computer and network security, and more particularly to techniques that employ a hardware appliance for securely storing and dispatching user identity information over a computer network. 
     2. Description of Related Art 
     There is considerable existing art in the area of identity. Existing concepts of identity focus on the ability to authenticate oneself onto a specific network and/or application, thus gaining access. Technologies such as OpenID for web services and Single Sign On (SSO) for enterprise applications provide login utilities that afford users the convenience of not having separate identities and login credentials for every application. Browser based keychains and password management software address the same problem in a different way by allowing the user to locally store all of their passwords in one place. 
     Identity and Access Management (IAM) systems allow enterprise system administrators to centrally manage access of users to particular applications. In addition, Identity Data Providers (IDPs) assert that a user is known to a provider and address Know Your Customer (KYC) requirements for certain industries and applications. IDP systems may optionally also provide additional user information to third party services. 
     SUMMARY 
     Unfortunately, prior solutions use a network-centric security model that employs a variety of technologies designed to keep bad actors out. The accumulation of disparate point solutions has increased complexity to a point where security problems cannot always be solved. Different applications often have their own security methods and privacy protection, making security difficult for users to understand and opaque even to the well informed. Users may circumvent security to avoid complexity. Further, information technology administration of security measures is expensive. Nevertheless, huge investments have been made in existing network paradigms, making a complete redesign impractical. What is needed is a change in the way activities are performed over computer networks that leverages existing network infrastructures and introduces elements that help to promote security at a fundamental level. 
     In contrast with prior approaches, an improved technique for promoting network security employs a user-centric approach in which a hardware appliance serves as a local security hub for storing and dispatching user identity information (UII). The hardware appliance, also referred to herein as a “vault” or “vault appliance,” is configured to release UII in response to access requests by applying a variable verification procedure. The variable verification procedure tests multiple verification factors associated with an access request, assigns a verification strength to each factor, and selectively releases the requested UII in response to a combined verification strength exceeding a threshold. 
     Advantageously, the improved technique is flexible in that it allows some verification factors, which may be relatively weak, to be compensated by other verification factors, which may be relatively strong, thus releasing the UII in response to legitimate requests. Conversely, the improved technique is able to block illegitimate requests even if some verification factors are strong, provided that others are weak. 
     Certain embodiments are directed to a method of securely dispatching user identity information (UII) of users on a computer network. The method includes storing, in non-volatile memory of a hardware appliance, (i) a set of UII of a user and (ii) a verification threshold that defines a total verification strength needed for accessing the set of UII of the user. The method further includes receiving, by the hardware appliance from a requestor, an access request to access the set of UII stored in the hardware appliance. In response to receiving the access request, the method further includes performing, by the hardware appliance, a verification operation, the verification operation: (i) testing multiple verification factors associated with the access request, (ii) producing, for each verification factor, a respective verification strength, (iii) combining the respective verification strengths to produce an overall result, and (iv) comparing the overall result with the verification threshold. The verification operation is configured (i) to release the set of UII to the requestor in response to the overall result exceeding the verification threshold and (ii) to block the set of UII from being released to the requestor in response to the overall result falling below the verification threshold. 
     Other embodiments are directed to a hardware appliance constructed and arranged to carry out a method of securely dispatching user identity information, such as the method described above. Still other embodiments are directed to a computer program product including a set of non-transitory, computer-readable media having instructions which, when executed by control circuitry of a vault appliance, cause the control circuitry to perform a method for securely dispatching user identity information, such as the method described above. 
     The foregoing summary is presented for illustrative purposes to assist the reader in readily grasping example features presented herein; however, this summary is not intended to set forth required elements or to limit embodiments hereof in any way. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
       The foregoing and other features and advantages will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings, in which like reference characters refer to the same or similar parts throughout the different views. 
         FIG. 1  is a block diagram of an example vault appliance and local environment in which embodiments of the techniques hereof can be practiced. 
         FIG. 2  is a block diagram of an example network environment in which embodiments of the techniques hereof can be practiced. 
         FIG. 3  is a block diagram of example data elements stored within the vault appliance of  FIG. 1 . 
         FIG. 4  is a block diagram of example data elements stored in a recovery key, which may be used to restore operation of the vault appliance of  FIG. 1  after an erasure event. 
         FIG. 5  is a block diagram of example verification data that may be stored in the vault appliance of  FIG. 1 . 
         FIG. 6  is a block diagram of example user data that may be stored in the vault appliance of  FIG. 1 . 
         FIG. 7  is a graph showing an example arrangement for performing verification based upon multiple factors in response to a request to dispatch a right, which may include a right to access user identity information (UII). 
         FIG. 8  is a flowchart showing an example method for performing verification using the arrangement of  FIG. 7 . 
         FIG. 9  is a block diagram of an example uniform right format for defining a right. 
         FIG. 10  is a block diagram of an example arrangement in which a user accesses the user&#39;s home vault from another vault&#39;s location; 
         FIG. 11  is a block diagram of an example call-back arrangement for dispatching a communication right that involves a second vault. 
         FIG. 12  is a block diagram of an example arrangement for authenticating a vault to a vault name server (VNS). 
         FIG. 13  is a block diagram of an example arrangement for dispatching a content right. 
         FIG. 14  is a block diagram of an example arrangement for dispatching an action right. 
         FIG. 15  is a flowchart of an example method for performing activities over a network using the vault appliance of  FIG. 1 . 
         FIG. 16  is a diagram showing an example verification factor having an upper bound, a lower bound, and an assigned level. 
         FIG. 17  is a block diagram shown an example trust hierarchy in the vault network. 
         FIG. 18  is a sequence diagram showing an example sequence of events for performing an introduction using a bootstrapping approach. 
         FIG. 19  is a simplified view of screen display of an app running on a mobile device for assisting with performing introductions. 
         FIG. 20  is a top view of two Universal Keys mated together to execute part of an introduction protocol. 
         FIG. 21  is a sequence diagram showing an example sequence of events for performing an introduction using Universal Keys and other compliant mobile devices. 
         FIG. 22  is a sequence diagram showing an example sequence of events for performing an introduction using a business card. 
         FIG. 23  is a block diagram showing an example manner of establishing associations between objects. 
         FIG. 24  is a flowchart of an example method for securely dispatching user identity information (UII) of users on a computer network. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Embodiments of the invention will now be described. Once should appreciate that such embodiments are provided by way of example to illustrate certain features and principles of the invention but that the invention hereof is not limited to the particular embodiments described. 
     This document is presented in the following sections to assist the reader:
         Section I presents an example vault appliance and environment in which embodiments of the invention may be practiced.   Section II presents particular improvements related to controlling, sharing, and proving identity, referred to herein as Identity as a Service (IDaaS)
 
Section I: Vault Appliance and Environment
 
Overview:
       

     An improved technique for promoting network security employs a vault appliance that serves as a local security hub for users and their devices. The vault appliance stores user information and definitions of “rights,” i.e., activities that user devices may perform, and securely dispatches those rights in response to right-requests and subject to user and/or device verification. 
     In some examples, the vault appliance (or simply, “vault”) is a hardware device having an established physical location within a range of a local network. The vault appliance is connected to the local network, through either a wired or wireless connection (preferably wired), and the range of the network forms a local, or “home” region. In an example, the vault is configured to recognize whether a device is located within the home region and to use that information when responding to right-requests. For example, the vault may subject right-requests originating from devices within the home region to less rigorous scrutiny than it does for right-requests originating from outside the home region. 
     In some examples, the vault supports right definitions in the form of content rights (to access particular content), communication rights (to communicate with another party), and/or action rights (to control a particular element). Rights may be user-defined through secure user interaction with the vault appliance, with the vault appliance storing user-defined right definitions in a uniform rights format. In some examples, users define verification requirements on a per-right basis, such that the criteria that the vault applies in dispatching rights may vary from right to right. 
     In some examples, the vault dispatches rights subject to a variable verification process. For instance, requirements for verifying a right may include multiple criteria, with each criterion making a contribution to an overall verification strength. If the overall verification strength exceeds a predefined threshold, verification may succeed; otherwise, it may fail. Verification can thus be flexible, with strength of some criteria compensating from weakness in others. In some examples, verification may require that certain criteria be satisfied unconditionally, such that verification will fail if any of those criteria fails to be met, even if overall verification strength exceeds the threshold. 
     In some examples, the vault appliance may be provided with one or more service modules. Each service module is registered with the vault appliance and is configured to control respective equipment in the home region. Such equipment may include, for example, one or more gaming systems, home or office security components, HVAC (Heating, Ventilation, and Air Conditioning) components, home entertainment components, or smart home or office components. Service modules may connect to the vault appliance over the local network, just like any other device, or they may connect via a dedicated network, bus, or backplane, for example. 
     In some examples, the vault appliance is provided as a battery-backed unit equipped with a set of motion sensors. When the motion sensors detect movement of the vault appliance that exceeds a predetermined distance, the vault is configured to erase certain contents to render the vault inoperative for dispatching rights. Therefore, thieves hoping to access rights cannot benefit from stealing a vault, as the rights stored in the vault are destroyed upon movement. In an example, a user may create a recovery key, e.g., in the form of a small device, such as a USB memory stick, which the user may store in a safe location and use for restoring erased content, e.g., if a stolen vault appliance is recovered or if the vault appliance is inadvertently erased. 
     The security benefits of the vault appliance can be more fully realized when multiple parties employ vault appliances. For example, users and/or devices may each be associated with a “home vault” in a respective home location, with communication rights involving not only verification of users and/or devices to their respective home vaults, but also verification of the vaults to each other. Multiple vault appliances across different locations may form a vault network, which is supported by a set of servers on the Internet. 
     In an example, the servers may include a vault name server (VNS), which stores vault identifiers (vault IDs) and associated network addresses (e.g., IP addresses). A call-back protocol may employ the VNS to promote secure communications between vaults. For example, when a first vault receives a right-request to communicate with a user, device, server, application, or other element supported by a second vault, the first vault may send a connection request to the second vault. The connection request includes the vault ID of the first vault. Upon receiving the connection request, the second vault may contact the VNS to look up the network address of the first vault and may contact the vault at the network address received from the VNS. Only if the connection request was originated from the received network address stored in the VNS can the communication proceed. Vault impersonators can thus be blocked and flagged. 
     In some examples, the set of servers may include a User Public Identifier (UPID) Name Server (UNS) that associates user public identifiers (UPIDs) with respective home vaults. In an example, a foreign user registered with a foreign vault may attempt to access a right stored on the foreign vault from a location of another user&#39;s home vault. To access a right from the foreign vault, the foreign user may send a request to the home vault at the current location. The request includes the foreign user&#39;s UPID. The home vault contacts the UNS to look up the network address of the home vault of that UPID. The local home vault then contacts the vault at the received address and, assuming the foreign user is registered with the vault at the received address, a secure session is established between the foreign user&#39;s device and the foreign vault. The foreign user can then send a right-request to the foreign vault over the secure session to exercise the right. 
     In some examples, a user may wish to access a right from outside the location of any vault, i.e., while roaming. In these examples, the user&#39;s device may be configured with basic vault functionality to enable the roaming device to establish a secure session with the user&#39;s home vault, e.g., in a manner similar to that described above. 
     In some examples, verification strength can be improved with the use of tags, i.e., physical devices whose presence can be detected by devices when the tags are located close by, e.g., using Bluetooth or WiFi. The tags (or a single tag) may be registered with a user&#39;s home vault, and detection of a tag in a vicinity of the device from which a request originates can increase verification strength, which may be particularly helpful in roaming scenarios. 
     In some examples, the vault network is a closed, self-defending network that employs protocols for maintaining security, which may exclude users, devices, applications, and/or vaults from participating if they violate vault network protocols. 
     In some examples, the use of vaults is not limited to home or office use and may extend to resources available over the Internet, such as public websites, data sources, and the like, with communications with and between such resources governed by the same vault protocols as described herein. 
     Example Implementation 
       FIG. 1  shows an example environment  100  in which embodiments of the improved techniques hereof can be practiced. The environment  100  is seen to include an electronic device  110 , a vault appliance  140 , and a local area network (LAN)  180 . A switch/router  182  provides an interface between the LAN  180  and a wide area network (WAN)  220 , such as the Internet. The electronic device  110  may be any network-connectable device, such as a desktop computer, laptop computer, tablet, smart phone, set top box, gaming system, smart wearable, vehicle, or the like, and the environment  100  may include any number of electronic devices  110 . Such devices  110  may be connected to the LAN  180 , using wired or wireless (e.g., Wi-Fi) connections, and are thus discoverable on the LAN  180 . The environment  100  may also include any number of service modules  176 . The service modules  176  are special types of electronic devices  110 , which serve particular functions within the electronic environment  100 , such as to control gaming systems, home security components, HVAC components, home entertainment components, smart home or office components, and the like. In some implementations, the service modules  176  have a direct connection to the vault appliance  140 , e.g., via a specialized network, bus, or backplane. The environment  100  may include various smart elements  184 , such as smart appliances, gaming systems, smart TVs, and the like. Such smart elements  184  are also connected to the LAN  180 , using wired and/or wireless connections. In an example, each smart element  184  has a lock  184   a  (e.g., a password and/or encryption key), which must be presented in order to control the element. The vault appliance  140  preferably has a direct, wired connection to the switch/router  182 , although this is not required, as in some examples the vault  140  may be connected to the LAN  180  by any means, e.g., using a cable or wirelessly. 
     The electronic device  110  (or each such device) may include one or more communication interfaces  112 , such as Ethernet cards, Wi-Fi adapters, etc., one or more processing units  114 , such as processor chips or assemblies, and memory. The memory may include volatile memory  120 , e.g., DRAM (Dynamic Random Access Memory), as well as non-volatile memory  130 , e.g., one or more magnetic disk drives, solid state drives, chips, and the like. The volatile memory  120  may “include” (i.e., implement by software instructions that run on the set of processors  114 ) an operating system, as well as various applications, processes, and daemons. Included among these is agent  122 , which provides executable code for communicating with the vault  140  (or other vaults) in accordance with vault protocols. In an example, the agent  122  is installed on the electronic device  110  specifically for the purpose of operating in a vault-based network. The non-volatile memory  130  may store data elements that enable successful communication with the vault  140 , such as a UPID (User Public Identifier)  132   a  and a device identifier (device ID)  132   b . In an example, the UPID and the device ID are each globally unique identifiers. 
     In a similar fashion, the vault appliance  140  includes one or more communication interfaces  142  (e.g., Ethernet cards, Wi-Fi adapters, Bluetooth adapters, etc.), a set of processing units  144  (e.g., chips, cores, assemblies, etc.), and memory, which may include volatile memory  150  (e.g., DRAM) and non-volatile memory  160  (e.g., magnetic and/or solid state devices). The volatile memory  150  includes an executive  152 , which runs a rights verifier  154 . The non-volatile memory  160  stores a host of information, such as user IDs  162   a  (e.g., of users registered with the vault  140 ), device IDs  162   b  (e.g., of devices registered with the vault  140 ), user information  162   c , encryption keys  162   d , passwords  162   e , rights definitions  162   f , and a distance threshold  162   g . Preferably, the vault  140  stores identity data, passwords, keys, and rights, such that there is no need for the device  110  to store this information. For example, the user  102  need not remember passwords, keys, codes, answers to challenge questions, or the like. In some examples, a single vault password is the only user or verification information that the user  102  needs to remember. 
     The vault appliance  140  may further include a set of motion sensors  170 , such as one or more accelerometers, and one or more batteries  172 . Although the vault appliance  140  preferably has a line cord  178  for receiving line voltage, the batteries  172  provide backup power and keep the vault  140  functioning for a period of time after power has been removed. 
     The vault appliance  140  is preferably a small, low-power hardware device, which runs coolly enough to be contained within a locked box or other enclosure without overheating. The vault appliance  140  may have a user interface  175 , although a service module  176  may present a user interface on behalf of the vault appliance  140 . Preferably, any such user interface  175  is highly constrained so as to permit a limited number and scope of operations, such as to register users and devices, to define rights, and to run recovery operations in the event of data loss. The user interface  175  preferably does not support local installation of program code, Also, the vault appliance  140  preferably provides no provision for users to log on remotely; i.e., any attempt to register devices, define rights, modify rights, change user profile information, and so forth must generally be performed locally at the user interface  175 . Insisting that users only change vault settings when local to the vault  140  further promotes security. 
     In example operation, a user  102  of an electronic device  110  wishes to perform some activity that involves accessing and dispatching one or more rights  162   f , which have been defined and stored in the vault appliance  140 . The rights  162   f  may take the form of content rights, communication rights, and/or action rights, for example. Some activities may involve accessing and dispatching multiple rights  162   f . For instance, accessing content on a different device  110  may involve both a communication right to communicate with the other device and a content right to access a content element stored on the other device. 
     Dispatching a right  162   f  from the vault appliance  140  typically involves three sets of activities: (i) introduction, (ii) right-request, and (iii) verification. To initiate introduction, the agent  122  running on device  110  issues an introduction request  190  to the vault  140  (An “introduction request” may also be referred to herein as a “connection request.”). The introduction request  190  may include the UPID  132   a  of the requesting user  102  and the Device ID  132   b  of the originating device  110 , for example. The introduction request  190  preferably sends encrypted versions of these elements. In some examples, the electronic device  110  stores the elements  132   a  and  132   b  in encrypted form, with no access to their plaintext values. The device  110  may send the introduction request  190  over the LAN  180  (wired or wirelessly). Alternatively, the device  110  may send the request by other means, such as using Infrared or other kinds of RF transmission. In some arrangements, introduction may require authentication of the device  110 . For example, the device  110  and the vault  140  may share a pair of deep blind secrets, and secure exchange and verification of these secrets may be required. Upon receipt of the introduction request  190 , the vault  140  performs introduction operation  190   a . For example, the vault  140  confirms that the UPID  132   a  has been registered with the vault  140 , e.g., that the UPID  132   a  has been stored among the list of User IDs  162   a  within the vault. In some examples, the introduction operation  190   a  also involves verifying the device ID  132   b , e.g., by confirming that the received device ID  132   b  can be found among the registered devices  162   b . However, confirming the device ID  132   b  is not required in some embodiments, as it may be desirable to allow the user  102  to connect to the vault  140  from an unregistered device. If the vault  140  confirms that the UPID  132   a  (and optionally the device ID  132   b ) have been registered with the vault  140 , then the introduction operation  190   a  succeeds and the vault  140  proceeds to establish a secure, point-to-point communication session  192  with the device  110 . The session  192  is private between the vault  140  and the device  110 , is protected by strong encryption, and cannot be spoofed. 
     Once the secure session  192  is established, the agent  122  running on the device  110  may issue a right-request  194  over the secure session  192 . The right-request  194  is a request to dispatch a particular, pre-defined right  162   f , which is stored in the vault  140 , e.g., a content right, a communication right, or an action right. In an example, the device  110  specifies the particular right by providing a right identifier (RID). 
     In response to receipt of the right-request  194 , the vault  140  performs verification operation  194   a . For example, the rights verifier  154  executes a right-specific verification procedure, which is defined within the requested right  162   f . Verification to the right is based upon multiple considerations surrounding the right-request  194 . The rights verifier  154  generates a verification result  156 , which indicates, for example, either success or failure. If the verification result  156  indicates a failure, the vault  140  may log the failure and prevent the requested right from being exercised. However, if the verification result  156  indicates success, the vault  140  may log the success and permit the requested right to be exercised. 
     The specific acts involved in exercising the right will depend upon the type of right and the particulars of its definition. For example, to exercise a content right, the vault  140  may securely provide a decryption key for unlocking the requested content and/or an encryption key for changing it. To exercise a communication right, the vault  140  may securely release a password or other data needed to communicate with another device (e.g., either on the local network or over the WAN/Internet  220 ). To exercise an action right, the vault may securely release any password or other information needed to perform an action on a smart element  184 . 
     In general, exercising any right involves accessing a secret  196  stored in the vault  140  in connection with the particular right  162   f . The secret  196  may take the form of a password, an encryption key, a decryption key, or any combination of these elements, for example. For exercising some rights, the vault  140  may securely send the secret  196  back to the device  110 , such that the device  110  may apply the secret  196  in performing the requested activity. In other examples, the secret  196  is securely dispatched elsewhere, such as to another device or element, or is used internally and never released. Preferably, secrets  196  are system created. The user  102  does not need to know the secrets  196  in order for the vault  140  to execute rights. Rather, secrets  196  are preferably hidden even from legitimate users. 
     In an example, the secure session  192  between the device  110  and the vault  140  is kept open to allow multiple right-requests  194  to be sent without having to repeat introduction each time. Either the device  110  or the vault  140  may end the secure session  192  explicitly at any time, or the session  192  may close automatically after a predetermined interval of inactivity. 
     The environment  100  also supports the use of tags  188 . In an example, tags  188  are small physical devices that the user  102  may carry on the user&#39;s person or have on hand to strengthen verification. For example, each tag  188  stores an identifier that can be read by the device  110  and/or the vault appliance  140 , e.g., using Wi-Fi, Bluetooth, or direct connection (e.g., USB). In some examples, tags  188  are registered with the vault  140 , and the vault  140  may associate each tag  188  with a password. When performing the verification operation  194   a  in response to a right-request  194 , the vault  140  may search for known tags  188  in the environment  100 , and/or the vault  140  may receive tag information from the device  110 . The presence of a registered tag  188  in the vicinity of the user  102  may be used as a blind factor to strengthen verification, such that it may be easier for the user  102  to authenticate to a right when a tag  188  is found than when it is not. 
     In some examples, once a verification operation  194   a  succeeds for one right-request  194 , a verification window may be kept open for a period of time for other right-requests  194 , during which time additional verification is not required unless additional factors are needed, e.g., for verifying right-requests  194  that require different factors. In some examples, the verification window may be set to zero, such that each right-request  194  must be independently verified. 
     In preferred use, the vault appliance  140  has a fixed location within a home or office. For example, the vault  140  may be attached to a wall or panel, where it maintains a fixed position for its entire service life. In an example, all information stored in the vault is encrypted with local encryption keys also stored in the vault. To protect against theft of the vault  140  and its valuable secrets, the vault&#39;s motion sensors  170  are configured to detect movement of the vault  140 . For example, motion sensors  170  may include one or more accelerometers. In an example, the vault  140  measures outputs from the accelerometers and double-integrates the outputs with respect to time to produce values corresponding to distance traveled in 3-dimensional space. If the distance traveled exceeds a predetermined distance threshold (e.g., 10 meters, 100 meters, etc.), the vault initiates a self-erase operation, in which it erases the local encryption keys, rendering the vault  140  useless for the purposes of dispatching rights and disclosing secrets. The batteries  172  allow the vault  140  to retain power for at least enough time to detect movement and complete the self-erase operation. The vault appliance  140  is thus self-protecting in the event of theft. 
     If a stolen vault  140  is recovered, or if its contents are erased for reasons other than theft (e.g., as a result of the user relocating the vault), deleted contents may be restored using a recovery key  186 . In an example, the recovery key  186  is a USB memory stick or other memory device, which stores keys  186   a . The keys  186   a  are backup copies of the local encryption keys that were deleted from the vault  140 . To restore vault operation, the user  102  may plug in the recovery key  186  to a socket  174  of the vault (e.g., a USB port), and operate the user interface  175  to perform a recovery procedure. Upon completion of the recovery procedure, the vault  140  can resume normal operation. 
     Although the vault appliance  140  is preferably a hardware device, nothing prevents its operations and protocols from being implemented in software. Software implementations of the vault may be particularly attractive in data center environments, where the vault  140  may serve as a local security hub that supports one or more servers, websites, and the like. Data center environments are likely already to implement physical security measures that embodiments above are designed to provide, such that software applications are feasible without sacrificing security. In addition, the vault appliance  140  may be provided in the form of hardware configured as a blade or other circuit board assembly, which plugs into a card cage or other enclosure in a data center or other server environment. Further, the vault appliance  140  may be implemented as a custom chip or chipset, which forms a component of a larger electronic system. Thus, embodiments of the vault appliance  140  are not limited to any particular physical implementation. 
     As described, the vault appliance  140  acts as a personal security hub within the LAN  180 . The LAN  180  itself may provide a local region of the vault&#39;s reach, in the sense that any device  110  or tag  188  physically connected to the LAN  180  or in range of its Wi-Fi signal can participate in communications with the vault  140  over the LAN  180  and is deemed to be “local.” In some examples, the local region of a vault  140  may be determined more accurately. For instance, a map of a local region and its surroundings may be provided to the vault  140  or associated equipment. The vault may employ a transceiver (on board or separately) to triangulate the location of a device  110  relative to the map. The device  110  may be deemed to be local if the transceiver finds the device within the local region as indicated by the map; otherwise, the device  110  may be deemed non-local (e.g., remote). 
     In an example, locality to the vault  140  is a prominent factor in the verification operation  194  for certain rights. For instance, a determination that the device  110  is local to the vault  140  may significantly strengthen verification, such that much less proof is required for verification to succeed than if the device  110  were remote. 
     Further, one should appreciate that the benefits of the vault  140  may be more fully realized when multiple parties employ vaults  140  at respective locations. In these situations, vault appliances  140  may form a vault network, where rights may involve content access, communications, and/or actions between vault locations, including over the Internet at large. 
       FIG. 2  shows an example vault network environment  200  in which multiple vault appliances  140 ( 1 ) through  140 ( 4 ) provide security in respective local regions  210 ( 1 ) through  210 ( 4 ). Each local region  210  is established, for example, by a LAN within the respective local region  210  (e.g., by the reach of its network cables and/or Wi-Fi signals), by triangulation, or by any suitable method. Thus, for any interaction between a device  110  and a respective vault  140 , the device  110  may be deemed either to be local or not. 
     In the example shown, device  110   a , tag  188   a , and smart element  184  are all local to vault  140 ( 1 ) in region  210 ( 1 ), where user  102  is registered. Likewise, device  110   b  and device  110   c  are local to vault  140 ( 2 ) in region  210 ( 2 ), where user  104  is registered. Also, website  212  is local to vault  140 ( 3 ) in region  210 ( 3 ) and file server  214  is local to vault  140 ( 4 ) in region  210 ( 4 ). Although not shown, each region has a respective LAN, and each LAN is connected to the network  220 , e.g., through a respective router. 
     In an example, various servers connect to the network  220  to support vault network operations. These include a Vault Name Server (VNS)  230 , a User Public Identifier Name Server (UNS)  240 , and additional servers  250 . The VNS  230  stores a list of all registered vaults by vault ID and associates each vault ID with a respective network address, such as an IP (Internet Protocol) address where the vault can be found, and a public key of that vault. The UNS  240  stores a list of all registered users by user ID and associates each user ID with a respective “home vault,” which may be designated by vault ID. In an example, each user may be registered on any number of vault appliances  140  but has only a single home vault, which is generally the vault  140  within the user&#39;s home or office. Additional servers  250  may be provided as follows:
         Vault Backup Server (VBS)  252 . Stores encrypted backup files of vault contents; may be used for vault recovery.   Classification Server (CLS)  254 . Stores identities of all registered elements on vault network (e.g., vaults, devices, tags, users, applications, smart elements, etc.)   Token Server(s)  256 . Offers content rights for sale or trade to vault network members.   Service Provider Server(s)  258 . Other servers (e.g., in addition to website  212  and file server  214 ) that provide services to users in accordance with vault network protocols.
 
Although the vault network servers  230 ,  240 ,  252 ,  254 ,  256 , and  258  are shown as respective computers, this is merely an example, as the servers may be implemented using any number of computers, including a single computer. Further, each server may be implemented with any number of computers.
       

     The vault network environment  200  supports a variety of secure operations between user devices  110  and vaults  140 , between different vaults  140 , and between different user devices  110  as supported by one or more vaults  140 . For example, the vault network  200  allows one user to securely communicate with another user, via communication rights, both within a single local region  210  and between local regions  210 . The vault network  200  also allows a user to securely access content both within and between local regions  210 , via content rights, and to control smart elements  184  both within and between local regions  210 , via action rights. 
     For dispatching rights across two local regions  210  in accordance with some examples, vault network protocols may require that the vault  140  in each local region first verify that the vault  140  in the other local region is a legitimate member of the vault network  200 . For instance, each vault may perform a lookup of the other vault in the VNS  230 . In such cases the requested right may then be exercised only if both vault identities are confirmed. 
     In some examples, a request from a user of one vault  140  to communicate with a user, device, or resource of another vault  140  involves a call-back procedure to confirm the requestor&#39;s identity. For instance, if a request to communicate is sent from a user on a first vault to a device on a second vault, the second vault may look up the home vault of the requesting user on the UNS  240  to confirm that the user is legitimate. Assuming the user is legitimate, the second vault may contact the vault at the address obtained from the UNS  230  to confirm that the vault is indeed waiting for a connection, which would be the case if that vault is truly the vault through which the user initially made the request. Exercise of the right may only proceed if confirmation succeeds. 
     Also, if a user in one local region  210  wishes to exercise a right, but the user&#39;s home vault is in a different local region, vault network protocols may require that a local vault receiving the user&#39;s request first perform a lookup of the user in the UNS  240 . Only if the user is confirmed to be a legitimate member of the vault network  200  can activities for exercising the right proceed, with the local vault contacting the user&#39;s home vault at an IP address received from the VNS  230 . 
     In some examples, the vault network  200  also supports roaming, e.g., situations in which a user is not currently within any local region  210 . For example, as shown in  FIG. 2 , user  102  has left the local region  210 ( 1 ) of that user&#39;s home vault, but still has a connection to the network  220 , e.g., via a data network, cell phone network, Wi-Fi hotspot, etc. As the user  102  is not within the user&#39;s home region  210 ( 1 ), the verification operation  194   a  may be much more difficult to satisfy, as verification strength outside the local region  210 ( 1 ) may be low. The use of tag  188   a  may help to strengthen verification, however, as the tag  188   a  may at least partially compensate for the fact that the user is not in any local region  210 . According to some variants, the user&#39;s device  110   a  may include software for implementing rudimentary vault functionality, such that the roaming device  110   a  may act as a non-home vault in communicating with other elements on the vault network  200 . 
       FIG. 3  shows example data elements  300  that the vault  140  (or any of vaults  140 ( 1 ) through  140 ( 4 )) securely stores. The data elements  300  include the following:
         Vault Configuration Information  310 : Includes unique vault ID (VID)  312  of the vault  140  and a vault owner, who is preferably a user of the vault  140 . In an example, the vault owner is identified by a UPID. This vault configuration information  310  is “Protected” because a secret stored in the vault data  340  (below) gates the ability to write this information  310 . The secret is also stored in compare-only non-volatile storage (e.g., in a register). To allow writing to or modification of the vault configuration information  310 , the secret from the encrypted vault data  340  is presented to the register, with a match enabling configuration changes to proceed.   Vault Network Addresses  320 : Includes network addresses (e.g., IP addresses) of the vault  140 , as well as those of the VNS  230 , UNS  240 , VBS,  252 , and CLS  254 , for example.   Vault Network Keys  330 : Encryption/decryption keys (symmetrical or asymmetrical) for communicating with other elements of the vault network  200 , including:
           Public and private keys for the vault  140  (Kpu and Kpr);   Public and private keys for each device registered with the vault  140  (Kdpu and Kdpr);   A public key (Kpuvns) for the VNS  230 ;   A public key (Kpuuns) for the UNS  240 ;   A public key (Kpvbs) for the VBS  252 ;   A public key (Kpucs) for the CLS  254 ;   Single use backup keys, for restoring vault content from VBS  252  (e.g., if recovery key  186  is lost or corrupted); and   Vault logging keys, used for securely storing logs of vault activities.   
           Vault Data  340 : Includes vault content, such as a list of users (by UPID) registered with the vault  140 , vault-level logs, verification data  342 , user data  344 , and rights definitions  346 . Includes types of data  162   a  through  162   f  from  FIG. 1 .   Core Vault Encryption Key  350 : Key used to encrypt vault data  340 .   Core Vault Decryption Key  360 : Key used to decrypt vault data  340 .   Deep Blind Associative Vault Identifier  370 : A first secret shared with the VNS  230  (and preferably ONLY with the VNS  230 ) and stored in a first register of the vault  140 . The vault  140  sends this identifier to the VNS  230  using one-time encryption key to confirm its identity to VNS  230 .   Deep Blind Associative VNS Identifier  380 : A second secret shared with the VNS  230  (and preferably ONLY with the VNS  230 ) and stored in a second register of the vault  140 . Used by vault  140  to compare against a value received in response to sending the identifier  370  to the VNS  230 . The received value is also encrypted using a one-time encryption key. A match between the received value and the identifier  380  ensures that the VNS  230  is the source of the received value. The second register is preferably writeable and comparable but not readable.       

     As further shown in  FIG. 3 , the vault network addresses  320 , vault network keys  330 , core vault encryption and decryption keys  350  and  360 , and deep blind associative identifiers  370  and  380  are all “Deleted on Movement,” meaning that the vault executive  152  ( FIG. 1 ) deletes these elements in response to the motion sensors  170  detecting movement of the vault  140  by a distance that exceeds a predetermined distance threshold. Deletion of these data elements renders the vault  140  incapable of responding to introduction requests  190   a  and right-requests  194   a  but leaves vault configuration information  310  and vault data  340  intact. These data are stored in encrypted form, however, and can only be read upon successful completion of a vault recovery operation. 
       FIG. 4  shows example contents of keys  186   a , which are stored in vault recovery key  186 , and which may be loaded into the vault  140  (e.g., via port  174 ) to perform a vault recovery operation. Here, it is seen that the keys  186   a  include the following:
         VID  312 ;   Core vault encryption key  350 ;   Core vault decryption key  360 ;   Deep Blind Associative Vault Identifier  370 ; and   Deep Blind Associative VNS Identifier  380 .
 
In an example, the keys  186   a  do not include all data that was erased, such as vault network addresses  320  and vault network keys  330 . Rather, these data elements may be recovered separately after basic vault operation is restored, e.g., by contacting vault network servers and authenticating to one or more of these servers using deep blind associative identifiers  370  and  380 . Note also that keys  186   a  do include VID  312 , even though VID is not erased upon movement, to ensure that the keys  186   a  are paired with the appropriate vault  140 .
       

       FIG. 5  shows example verification data  342  in additional detail. The vault  140  may apply this verification data  342  when performing verification operations  194   a . Preferably, this data  342  is not used when verifying a user to the vault  140 , which happens during the introduction operation  190   a , but rather in determining whether a particular write request  194   a  has been sufficiently verified. As shown, the vault  140  may store three types of verification data  342 : unshared user input  510 ; unshared user blind input  520 ; and shared input  530 . One should appreciate that the particular examples described herein are not intended to be exhaustive. 
     Unshared user input  510  refers to information that has been transmitted by a user to the vault  140  as user verification data. This category of verification data may include, for example, a hierarchical vault password  512 , a local vault password  514 , biometric data  516  pertaining to a user, and answers  518  to challenge questions  534 . The hierarchical vault password is a variable length/strength password that may be presented by user devices  110 , whereas the local vault password may be entered only locally at the vault  140 , e.g., via the user interface  175  ( FIG. 1 ). 
     Unshared user blind input  520  allows seemingly blind associations to be used as part of the verification operation  194   a . Such input  520  is “blind” because the user does not necessarily perform any deliberate act to use the input as part of verification. Examples of user blind input  520  includes identifiers  522  of object tags  188 . For instance, detection by the vault  140  or user device  110  of a tag  188  whose identifier matches an identifier  522  may increase verification strength, even if the user is not aware that this is happening. 
     Shared input  530  is information used for verification that is shared with a third party, which third party is not a vault  140  or a user of the vault  140 . Shared input  530  includes, for example, challenge questions  532 , challenge photos  534 , and identifying photos  536 . The challenge questions  532  are shared because the vault  140  may transmit them to a device  110 , which may present them to a user. Also, challenge questions  532  may be used in customary authentication on the user device  110  (e.g., outside the vault network  200 ) and in second-party authentication systems. A challenge photograph  534  is simply a form of challenge question that asks “What is this?” in the form of a photograph. Identifying photographs  536  may be photographs of the user or other authorized persons. For example, a payment system might display to an operator a vault-provided photograph of the user or other authorized purchaser, such as a child, which might enable the operator to confirm the purchaser&#39;s identity. 
       FIG. 6  shows example user data  344  in additional detail. User data  344  may include, for example, identifying data  610 , personal data  620 , and permissions  630 . 
     Identifying data  610  serves to identify the user and may include a physical description and various personal identifiers for use by legacy identification systems, such as the user&#39;s name, height, weight, hair color, social security number, passport number, and driver&#39;s license number, for example. Preferably, the vault network does not use identifying data  610  for verification; rather, the vault  140  may transmit identifying data  610  to interested third parties on a need-to-know basis. In some examples, the vault  140  may share biometric data  516 , this way as well, but this is not recommended. In an example, sharing of identifying data  610  is performed in connection with establishment or execution of a right. 
     Personal data  620  includes information that a user may wish to safely store, access, and/or share, such as phone numbers, email addresses, instant messenger (IM) addresses, medical data, and/or any other data. Users can define content rights to share personal data  620  with other parties, so users should exercise care in deciding which information to store and the level of verification to require of other parties who wish to access the information. For example, users may set a required level of verification to be commensurate with the importance or value of the data that the right protects. As with the identifying data  610 , sharing of personal data  620  is performed in connection with establishment or execution of a right. 
     Permissions  630  are actions that other components of the vault network  200  are allowed to perform on the user and/or the user&#39;s resources. For example, a component may deny service to a user who refuses to give permission for an action, e.g., when performing the action is part of the service being provided. There are cases in which the user has established permissions so as to prohibit an action, but the user is accessing a service or location that requires the action to be approved, such as with surveillance video. In such cases, the vault  140  may alert the user that video is being used. Thus, even in cases where the demands of the service provider must be protected (e.g., as with surveillance video), the vault network does not allow the prohibited action to proceed without informing the user. 
     Within the vault network  200 , vaults  140  may employ communication rights to store network-accessible account information. For example, information used by just one account (e.g. account number, user name, password) may be stored in a communication right for that account. In such cases, the communication right stores the identity of the other party, e.g., in an authentication list for that communication right. Information common to multiple accounts, such as name, address, credit card number, etc., may be stored in a user profile. Communication rights may specify conditions and limitations on access to user profiles. One should appreciate that each communication right is a right that exists between two parties, which parties may be identified by their respective UPIDs. Each party to a communication right has a right to communicate with the other party and may provide permissions that allow and/or restrict access to its information and to actions that are allowed to be performed on its data or resources by the other party. 
     In some examples, an implementation to access information in a user&#39;s profile associates an action field of a right with a piece of profile information. The action may specify “Read this piece of profile information,” for example. As verification to any right maps to a set of permissions, profile information can only be viewed to the extent that the right owner has established permissions to allow it. 
       FIG. 7  shows an example arrangement for variable verification, which may be performed by the rights verifier  154  ( FIG. 1 ) as part of a verification operation  194   a , i.e., in response to a right-request  194 . Here, multiple verification factors  710  each have a magnitude  720 , which establishes a strength of that factor&#39;s contribution to an overall verification strength. In this example, verification factors  710  include a user identifier, the device ID of the device  110  originating the request, the location of the device  110  (e.g., either local or non-local), the hierarchical vault password  512  (or some number of digits thereof), second party biometric data, and a third party photograph. As shown, the magnitudes  720  of factors  710  may differ from one another, such that some factors contribute more to overall verification strength than others. 
     In an example, the hierarchical vault password  512  permits one to use (and hence risk exposure of) a limited number of digits of the entire password to achieve desired authentication strength. In an example, each digit of the hierarchical vault password  512  adds a fixed amount of magnitude  720 , with a greater number of digits providing a greater magnitude  720 . It is recommended that the hierarchical vault password  512  be a system-derived random number. Humans can easily recall 7 to 10 digits. As the vault network  200  provides communication rights, which eliminate the need for users to memorize passwords and other information, the hierarchical vault password  512  results in a huge reduction of the total amount of information that a person must memorize to effectively live his or her digital life. 
       FIG. 7  shows three different right-request scenarios. In a first scenario (Scenario #1), the user is at home, i.e., in a local region  210  of the user&#39;s home vault  140 , and the right-request  194  to be verified originates from a known device  110 , i.e., a device that has been registered with the user&#39;s home vault  140 . Here, a sum of the magnitudes  720  of the individual factors for user, device, and location exceeds a predetermined verification threshold  730 , which must be exceeded for verification to succeed. In this scenario, variable verification does succeed, even without considering other factors. 
     In a second scenario (Scenario #2), the user again operates with a known device  110  (e.g., registered to the user&#39;s home vault) but the user is not local to the region  210  of the home vault. In this scenario, non-locality of the user reverses the sign of the location component, which here is seen to subtract from the overall verification strength. However, enough other factors  710  are satisfied to enable the sum of all factors  710  to exceed (just barely) the threshold  730 . Thus, variable verification again succeeds, although with a greater number of factors having to be considered. 
     In a third scenario (Scenario #3), a hacker has stolen a tag  188  from the user and holds the hierarchical vault password  512  for the user&#39;s home vault. But the hacker issues the right-request  194  from a location that is not local to the home vault. In this case, non-locality of the request again reverses the sign of the location component, which subtracts from the overall verification strength. Although the tag  188  may falsely verify the user&#39;s identity, the originating device is unknown and the hierarchical vault password  512  is not strong enough to enable the sum of magnitudes  720  to exceed the threshold  730 . Thus, variable verification fails in this scenario. 
     One should appreciate that different rights may involve different combinations of verification factors  710 . Thus, factors to be applied may depend on the right being requested, with the particular verification factors  710  to be used specified in the definitions of the particular rights. Although not shown, each right definition may specify a respective verification threshold  730 . For example, the threshold  730  may assume a higher value for certain rights (e.g., access my bank account) than for others (e.g., visit a website). 
     For some right definitions, certain factors  710   a  may be designated as mandatory. A mandatory factor  710   a  must be satisfied unconditionally in order for the verification operation  194   a  to succeed. 
       FIG. 8  shows an example method for performing the verification operation  194   a  in the manner described above. At  810 , the rights verifier  154  checks whether mandatory verification factors  710   a  are satisfied. Only if all are satisfied does operation proceed to  820 ; otherwise, verification fails ( 860 ). 
     At  820 , the rights verifier  154  computes overall verification strength  830  as a sum of magnitudes  720  of factors  710  used in verifying the particular right. At  840 , verification succeeds ( 850 ) only if the total  830  exceeds the verification threshold  730 ; otherwise, verification fails ( 860 ). 
       FIG. 9  shows an example common extensible format for defining a right in the vault  140 . The format shown in  FIG. 9  is intended to be common to all types of rights, including content rights, communication rights, and action rights. In an example, rights have the following characteristics:
         Common extensible rights format;   Common verification method;   Verification to specific permissions within a right;   Are contained and protected from threats by vaults  140 ; and   Are executed by vaults  140  uniformly for all right types.
 
Each right contains a list of permission sets indexed by a potentially unique combination of the various factors available for verification. Executing a right is synonymous with the vault  140  performing a transaction on behalf of a user.
       

     Here, right definition  346  includes a header portion  902 , a footer portion  904 , and a body  940 . The header portion  902  specifies a right owner  910  (e.g., the UPID of the user who defined the right), a right identifier (RID)  920  that uniquely identifies the right within the vault  140 , and a right type  930 , e.g., content, communication, or action. As UPIDs are preferably globally unique and each right is preferably unique to a particular user, the RID  920  need only be unique to the right owner  910 . 
     The footer portion  904  includes an authentication list  950 . The authentication list  950  includes an authentication index  952  and permissions  954 , which provide a subset of permissions stored in the body  940  of the right. The index  952  of an element on the list  950  contains the authentication requirements for that set of permissions. The authentication index  952  is composed of multiple factors. In some examples, the factor for user must always be present. 
     An authentication index  952  is defined by a set of values chosen for each of the included verification factors  710 . For example, the user, device, location, and specific threshold strength  730  could compose one index. This means that a specific user, using a specific device  110  in a specific location may also need to add arbitrary factors to achieve the required strength  730  in order to be verified for a given set of permissions. For any given verification attempt, the attempt may satisfy some set of verification indexes. The set is possibly empty. The union of all permissions, corresponding to the indexes in the set, forms the permissions that the user has available during the execution of the right. If the set is empty then the right is not executed. 
     The body  940  of the right includes three kinds of fields, an information field  942 , a selection field  944 , and an action field  946 . The number of fields of each kind depends on the type of right. 
     The information field  942  provides information and/or restrictions for the right, which must always be obeyed. Examples include:
         For a content right: maximum file size; encryption key;   For a communication right: a connection endpoint, such as a user, server, or element; minimum required bandwidth; password for the connected entity;   For an action right: Maximum RPM for a motor being controlled; password, element ID.       

     The selection field  944  represents a choice. The owner of the right selects the least restrictive choice that would ever be needed. This selection allows that choice and any more restrictive choices to be selected within the permissions  954  in the authentication list  950 . A simple example is a two-choice write/read selection field  944 . If “write” is selected, e.g. as S1 of selection  944 , then “read” (e.g., as S4) is automatically permitted because it is a more restrictive choice. As shown for Section 1 under permissions  944 , multiple choices for a single selection may be allowed. The choices are ordered from least restrictive (e.g., 1) to most restrictive (e.g., 4) and ordered that way in the selection list  944 . Examples of selection  944  for various rights may include:
         Content Right: Access, with selections: write, read, read summary, and read title.   Communication Right: Maximum data rate, with selections: 1 Gbit/sec, 500 Mbit/sec, and 50 Mbit/sec.   Action Right: Speed Control, with selections: 250 MPH, 85 MPH, and 65 MPH.
 
Although the number of selections in the selection field  944  is shown to be four, this is merely an example, as the number of selections may be user-defined and right-specific.
       

     As seen in Selection 1 under permissions  954 , the first choice is blacked out, meaning that this selection is not available to choose, in this case because the least restrictive selection available is the second choice. Here, we assume that, in the body  940  of the right, the owner has selected choice 2. Note that if one choice is not available, all lower numbered choices are not available, either. In this case, the owner has explicitly given this authentication index the permission for choice 3. Thus all more restrictive choices (e.g., choice 4) are implicitly allowed. 
     The action field  946  controls whether a single action is permitted for the object on which the right is to be executed during the time the right is being executed. When the execution of the right is complete, the ability to perform the action specified in the action field  946  is terminated. The action field  946  is not to be confused with the action right. With the action field  946 , the user has permission to execute the action but is not required to do so. With an action right, executing the right means performing the action specified. Examples settings of the action field  946  are given below:
         Content Right: Screenshot;   Communication Right: Mute; and   Action Right: Get status; start machine.
 
With the action field  946 , the above actions are permitted during the time the right is being executed but are not required, as the user may choose not to perform them.
       

     An application designed for the vault network  200  may create a specific instance of a right and add application-specific information to that instance. In an example, the vault network must approve all user-created and application-created instances of rights. The reason for this is twofold. First, rights must be verified to confirm that they abide by the rules of the vault network  200 . Second, it is the responsibility of the vault network  200  to author and distribute software to provide any new functionality required in vaults  140  to support new rights. 
     The common verification method for all rights helps in three very significant ways. First, it reduces the complexity of having a large number of different verification methods that a user may need, greatly reducing the amount of information that must be memorized or kept on hand in order to live ones digital life. The common verification method may include all online user accounts, all program accounts, all controls, and all protected data, for example. Second, reduction in complexity yields a corresponding reduction in bugs and therefore a corresponding increase in security. Third, storing rights on the vault  140  and verifying to the vault means that the device  110  does not need to carry any user verification information. Commercially available alternatives, such as password keychains, store verification information on-device. Such systems are vulnerable, however, as once a device containing a password keychain is compromised, many accounts may be compromised all at once. 
     In some examples, the vault  140  can defend intellectual property rights within a content right. This means that the owner of a content right cannot violate the rights of the intellectual property owner. In an example, the body  940  of the content right is broken up into two parts, one for the owner and one for the intellectual property owner. The intellectual property owner specifies what permissions it wishes to permit and deny for the given content. This includes the standard read/write/modify as well as which applications may be used and where the data may be stored or transmitted. The owner of the content right cannot make less restrictive choices than the intellectual property owner has made. The owner can, however, add his or her own additional set of independent restrictions, compliant with the fact that all content rights must be vault network approved. In an example, the owner can also further restrict any choice of the intellectual property rights owner. This is analogous to the generation of the permission list based on choices in the body  940 . For instance, if the owner of the intellectual property right gave write access, the owner could reduce this to just read access. 
     The intellectual property owner can also restrict access to the right via the verification process; example restrictions are locations or relative user, i.e. owner or members of owners vault. This is done in the body  940  of the right via an information field. The owner may also further restrict but not expand the choices of the intellectual property owner on its verification choices. The vault enforces restrictions from the intellectual property owner. 
       FIG. 10  shows an example arrangement  1000  in which the user  104  ( FIG. 2 ) with device  110   b  has left the region  210 ( 2 ) of his home vault  140 ( 2 ) and has traveled to local region  210 ( 1 ), where the local vault is vault  140 ( 1 ). At some point, user  104  may wish to exercise a right. Rights of user  104  are stored in vault  140 ( 2 ), but the local vault is vault  140 ( 1 ). In this case, when user  104  operates device  110   b  to exercise a right, device  110   b  sends an introduction-request  190  to the local vault  140 ( 1 ), e.g., over the LAN in region  210 ( 1 ). This introduction request  190  is labeled as step  1  and includes the UPID of the user  104 . 
     At step  2 , upon receiving the introduction request  190 , the local vault  140 ( 1 ) contacts the UNS  240  to perform a lookup on the UPID of user  104 . At step  3 , the UNS  240  returns the vault ID  312  of the home vault  140 ( 2 ) of user  104 . 
     Next, the local vault  140 ( 1 ) performs a lookup of that vault ID  312  on the VNS  240  (step  4 ). The VNS  240  returns the IP address and public key of the home vault  140 ( 2 ) (step  5 ). 
     At step  6 , the local vault  140 ( 1 ) contacts the home vault  140 ( 2 ) of the user  104  to indicate the user request  190 , providing its own vault ID  312 . The home vault  140 ( 1 ) contacts the VNS  240  (step  7 ) to validate the local vault  140 ( 1 ). For example, a response (step  7 ) from the VNS  240  includes the public key of the local vault  140 ( 1 ). The home vault  140 ( 2 ) attempts to communicate with the local vault  140 ( 1 ) using the public key at step  8 . At step  9 , the home vault  140 ( 2 ) informs the local vault  140 ( 1 ) that it has been validated, and at step  10  the local vault  140 ( 1 ) informs the device  110   b  that the home vault has been found and provides its IP address. 
     At step  11 , the device  110   b  establishes a secure, point-to-point session  192  with the home vault  140 ( 2 ), thus completing an introduction operation  192   a . With the secure session  192  established, the device  110   b  can proceed to send right-requests  194  to the home vault  140 ( 2 ), just as it would if it were local. 
     One should appreciate that the arrangement of  FIG. 10  may be realized between any two local regions  210 , with the local vault that receives the introduction request  190  from a device  110  first checking whether the it is the home vault for the UPID received with the request  190 . If so, the local vault handles the request. Otherwise, the local vault looks up the home vault for that UPID, contacts the home vault, and coordinates with the home vault in establishing a secure session  192  between the device  110  and its home vault. 
       FIG. 11  shows an example arrangement  1100  for performing a call-back procedure as a prelude to exercising a communication right. In this example, the user  102  operating device  110   a  wishes to exercise a communication right for communicating with website  212  in region  210 ( 3 ), whose home vault is vault  140 ( 3 ). As communication rights are typically between two UPIDs, the user  102  is one UPID and the website  212  is another UPID. The website  212  also functions as a device in this example. 
     At  1   a ′, the device  110  notifies its home vault  140 ( 1 ) that a request is pending to the remote UPID, i.e., to the website  212 . At or around the same time, step  1   b ′ is performed, in which the device  110   a  notifies the remote UPID (website) that the user  102  would like to communicate. The transmission at step  1   b ′ may be outside the scope of the vault protocols. At  2 ′, the website  212  informs its vault  140 ( 3 ) that the communication is pending. 
     At  3 ′, the remote vault  140 ( 3 ) performs a lookup of the user  102  on the UNS  240 . At  4 ′, the remote vault  140 ( 3 ) obtains the home vault  140 ( 1 ) of the user  102  from the UNS  240 . At  5 ′, the vault  140 ( 3 ) contacts the vault  140 ( 1 ) to ask whether a request for communication is pending. 
     Assuming so, then at  6 ′ and  7 ′ the two vaults  140 ( 1 ) and  140 ( 3 ) exchange session keys, which are passed to the respective devices at  8   a ′ and  8   b ′. At  9 ′, with the session keys in place, the device  110  may proceed to communicate securely with the website  212 . 
       FIG. 12  shows an example arrangement  1200  in which the vault  140 ( 1 ) authenticates to the vault network  200 . The process begins at  1 ″, where the vault  140 ( 1 ) sends a request  1210  for vault authentication to the VNS  230 , which responds at  2 ″ with a benign message  1220  that is encrypted using the public key of the vault, Kpu ( FIG. 3 ). At  3 ″ the vault  140 ( 1 ) decrypts the encrypted message with its pre-issued private key, Kpr. At  4 ″ the vault  140 ( 1 ) sends the decrypted message  1230  back to the VNS  230 , which performs (at  5 ″) a comparison  1240  between the received, decrypted message  1230  and an expected value. The comparison  1240  either succeeds (if there is a match) or fails (if no match). At  6 ″ the VNS  230  sends the comparison result (success or failure)  1250  back to the vault  140 ( 1 ). 
     In some circumstances, even stricter vault authentication may be required. In such cases, vault authentication may proceed using the pair of deep blind associative identifiers  370  and  380  ( FIG. 3 ) in the manner described above. 
       FIG. 13  shows an example arrangement  1300  for exercising a content right. For content rights, the secret  196  is a key  1310  used to encrypt/decrypt the content element, e.g., a file. Encryption/decryption is performed on vault network-approved devices with vault network-approved applications. A secure session  192  is established, in the manner described above, to pass the key  1310  to the device  110 . The device  110  requests access to the key  1310  and may use the key until the key is released. To achieve intended operation, the device  110  must follow three simple rules. First, the device  110  may not pass the key  1310  to any third party. Second, the device  110  may not store the key  1310  in non-volatile memory. Third, the device  110  may not store the key  1310  after the application that used the key has been closed. 
       FIG. 14  shows an example arrangement  1400  for exercising an action right  1420 . For action rights, the secret  196  is an identifier/password pair ( 1410 / 184   a ) for the smart element  184  to be controlled. In some examples, the elements  184  on which actions  1420  are performed must be within the local region  210  of the vault  140  that contains the relevant action right. The purpose of requiring locality is to ensure that the complete extent of the connection to the element  184  is under control of the vault  140  and associated location-determining equipment (e.g., LAN  180 , triangulation equipment, etc.). The vault  140  and equipment locate the element within the local region  210 . For an element  184  that has a fixed location, the system may confirm that the element has not moved, which might indicate a cloning attack. The vault  140  and location equipment also ensure that the element  184  is not cloned from outside of the local region  210 . 
     In an example, elements  184  within the local region  210  of the vault  140  are protected by protocols that encrypt data being sent. These protocols may use rolling encryption keys to ensure that no two messages for the same command can be detected as being the same over the air. Each transaction to the element  184  uses a specific rolling key. During each transaction, the key to use for the next transaction is agreed upon. If the control vocabulary of an element only contains two words, such as On and Off, encryption by itself would be meaningless, as a hacker would merely have to replay the encrypted message to control the element  184 . Rolling encryption keys ensure that each command sent to an element uses a different encryption key and thus appears to be completely uncorrelated with any other command. 
       FIG. 15  shows an example method  1500  that may be carried out in connection with the environment  100 . The method  1500  is typically performed, for example, by the software constructs described in connection with  FIG. 1 , which reside in the memory  150  and  160  of the vault appliance  140  and are run by the set of processing units  144 . The various acts of method  1500  may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from that illustrated, which may include performing some acts simultaneously. 
     At  1510 , an introduction-request  190  is received by a vault appliance  140  from an electronic device  110  over a network  180  and/or  220 . The introduction-request  190 —request initiates an introduction operation  190   a  between the electronic device  110  and the vault appliance  140 , the introduction operation  190  ( i ) confirming an identity of a user (e.g.,  102 ) of the electronic device  110  by matching a user identifier (UPID) received from the electronic device  110  with a user ID (one of  162   a ) stored within the vault appliance  140 , and (ii) in response to the identity of the user  102  being confirmed, establishing a secure, point-to-point session  192  between the electronic device  110  and the vault appliance  140 . The vault appliance  140  stores user information  162   c , passwords  162   e , and encryption keys  162   d  for promoting secure activities over the network. 
     At  1520 , within a context of the secure, point-to-point session  192 , the vault appliance  140  receives, from the electronic device  110  over the network  180 / 220 , a right-request  194  to exercise a right on the network, the right having a predefined description  162   f  stored in the vault appliance  140 . 
     At  1530 , in response to receiving the right-request  194 , the vault appliance  140  performs a verification operation  194   a , the verification operation  194   a  is configured to (i) produce a successful result  850  in response to a set of verification factors  710  being satisfied and (ii) produce an unsuccessful result  860  in response to the set of verification factors  710  not being satisfied, the vault appliance  140  configured to permit the requested right to be exercised on the network in response to the verification operation  194   a  producing the successful result  850  and to prevent the requested right from being exercised on the network in response to the verification  194   a  operation producing the unsuccessful result  860 . 
     An improved technique has been described for promoting network security. The technique employs a vault appliance  140  that serves as a local security hub for users and their devices. The vault appliance  140  stores user information and definitions of rights, i.e., activities that user devices may perform, and securely dispatches those rights in response to right-requests and subject to user and/or device verification. 
     The vault appliance  140  and vault network  200  offer many advantages over conventional systems for providing network security. For example, the vault network  200  is self-defending in the sense that any component of the vault network  200  can be removed from the network for violating protocols. It is not possible for a user to cause a legitimate vault  140  to violate vault network protocols. Hence, if a vault is detected to have violated vault network protocols, that vault is assumed to be altered and is immediately removed from the vault network  200 . Further, the owner of the vault may be held responsible and removed from the vault network as well. 
     Protocols in the vault network share a common feature that they are all involve transactions that are expected to be completed with a purpose. This means that if one vault contacts another vault, the initiating vault is expected to make a valid request and to complete the transaction. 
     There are classes of protocol violations for which the vault network servers should not immediately eject an offending vault. Instead, these types of violations may be logged and a vault may be removed from the vault network  200  only after a pattern of malicious behavior is detected with certainty. For example, to filter out premature terminations of transactions due to user or device interaction, a vault  140  is required to inform the vault network servers of such termination and give a reason. To filter out connection or network problems, a new transaction cannot be started by a vault until the previous transaction has completed. This implies that violations of incompletion are not immediately detectable, but rather are detected only after the vault attempts to start a new transaction. To filter out state loss in the vault that could occur with power loss, the vault is required to inform the vault network servers when it reboots. 
     In an example, the vault network  200  also defends against a second class of violations—behavioral violations. A behavioral violation is one that does not violate a protocol but instead violates a core principal of the vault network  200 . Unlike protocol violations, where removal from the vault network may be immediate, behavioral violations require a pattern a behavior before the offending user is removed. When a vault encounters a behavioral violation, that vault reports the violation to a central server. The central server looks for patterns of repeated bad behavior from users and deals with them appropriately. Examples of behavioral violations include:
         Requesting access to a right that does not exist. The most common form of this may be the content right, where the content right has been removed but the encrypted data still exists somewhere;   Requesting access to a right that the user is not authorized to access. Same as above;   Connecting to a vault without making a request;   Requesting the home vault of a user from the vault network servers without contacting that home vault in the same session; and   Requesting the address and public key of a vault from the core servers without contacting the vault in the same session.       

     The behavioral violations are flagged because either someone is trying to gain insight into another person&#39;s rights or that person is attempting to gather information about the vault network itself. The vault network is preferably closed, and no third party is allowed to make a map of the vaults contained within the vault network. That is the job of the vault network servers. It is also against vault network principles for a third party to create a user directory. These are the driving forces behind the behavioral violations. Behavioral violations are caught via logging. 
     As the vault network is closed, only members or components of the vault network will get a response from the vault network servers or vaults. The servers are generally the only components of the vault network with well-known addresses available on DNS (Directory Name System) servers. The two above facts make it impossible for a non-member of the vault network to create a map or directory of the vault network and/or its users. 
     The vault network securely logs all transactions. For a given request, the component of the vault network that provides the service and is responsible for defending the requestor is the component that performs the logging. Thus, the vault logs all transactions associated with the execution and management of rights, as well as all modifications to the user profiles of all members on the vault. The servers log all requests from the users and vaults for the services they provide. 
     Logging of transactions provides benefits to all participants. Users protect themselves against fraudulent claims of action. Rights represent things of value. Hence, if someone is accused of using the thing of value, they can prove that they did not, or in cases of misuse, exactly how they used the right. The vault network protects itself against bad behavior of users. Also, law enforcement can use the logs to help with legitimate law enforcement concerns. The communication right creates an encrypted session through which two end users can communicate. Without the logs, these communications would be hidden and hence enable nefarious people could perform nefarious deeds. Any right that is executed during the commitment of crime is logged, aiding law enforcement. Law enforcement may also subpoena the owner of a vault for the vault and vault recovery key  186  to obtain access to the content of logged communications. 
     In a traditional content protection system, the same system holds both the address of the content as well as the key for that content. Such systems have to be able to address the content before they can associate the key with the data; thus, they are inherently limited to access of content in the addressable domain. For encrypted data to exist on arbitrary systems in a uniformly available manner, the component storing the encryption keys cannot track the location of the encrypted data. If one were to confine data to a specific address type the problem could be solved, but even the most generic of address types cannot address all data. If, however, a specific user stores all of his encryption keys for data that he owns in one known place, the problem of associating encryption keys with encrypted data can be solved. In the vault network, each user has a UPID, which is a globally unique user ID. Each user can, through his vault, give a unique content identifier to each of that user&#39;s pieces of content. This content identifier is unique for the user. The combination of the globally-unique user identifier and user-unique content identifier forms a globally unique content identifier. Therefore, any application that chooses to access a vault network-encrypted file simply needs to look into the header to find unique identifier and then request access from the file owner&#39;s home vault. The UNS  240  maps UPIDs to home vaults. Hence, any legitimate member of the vault network may ask for the home vault of the owner. Note that only members of the vault network are permitted to contact the servers. A content right protects the encrypted file so only those authorized users as specified by the owner may access the file. Further, it is a violation of vault protocols to ask a vault for permission to access a file to which one does not have permission to access. A user who does this too many times in the vault network can be removed from the vault network altogether. 
     The basic model of the vault network for encrypted data is that the encrypted data may exist anywhere in any form without restriction. The decrypted data must however remain on approved vault network hardware and use approved vault network applications. This is to insure that the encryption keys remain safe and deleted after use on the devices that utilize them. It is the job of the applications to track and manage the data in a manner consistent with the requirements of the application. The number of permitted copies of the data is controlled from within the content right. The content right does this by limiting the number of users to which it sends the encryption keys. Users must request and release access to the encryption keys while at no time storing encryption keys in non-volatile memory for later use. This is done because the encrypted data is not guaranteed to be in the scope of the vault network and hence an arbitrary number of copies of the encrypted data could be made. 
     Section II: Identity as a Service (IDaaS) 
     An improved technique for promoting network security employs a hardware appliance that serves as a local security hub for storing and dispatching user identity information (UII). The hardware appliance is configured to release UII in response to access requests by applying a variable verification procedure. The variable verification procedure tests multiple verification factors associated with an access request, assigns a verification strength to each factor, and selectively releases the requested UII in response to a combined verification strength exceeding a threshold. 
     The security model of the vault network as described above relies on identity as a foundation. The vault network user-centric security model is in contrast to the existing network-centric security models that use a variety of technologies designed to keep bad actors out. In an example, only known users and devices are allowed on the vault network. The user-centric model unifies interactions for the user. Control actions, content exchange, and communications are all affected by transactions on the vault network. For example, every transaction involves verification of user identity and verification that the user has the right to initiate the desired transaction. This process is provided as a service to applications and web services that use the vault network. We refer to this service as Identity-as-a-Service (IDaaS). 
     In an example, IDaaS includes the functionality of a login utility as well as IDP, and allows for IAM functionality. However, the purpose of IDaaS is much broader. Identity as delivered through IDaaS can be thought of as representing digital personhood. The term “digital” covers information as well as the capabilities and ownership relationship to network-connected physical assets. In this context, we define user identity information (UII) as a collection of information tied to a globally unique identifier (e.g., a UPID) that:
         Describes the user.   Describes, protects, and makes available the user&#39;s capabilities.   Describes and protects the user&#39;s digital assets.   Describes and protects the user&#39;s network-connected physical assets.   Describes and protects the relative position of the user&#39;s network-connected physical assets when in the proximity of a vault.       

       FIG. 6  shows examples of UII  610 . Additional non-limiting examples of UII may include weight, hair color, social security number, passport number, driver&#39;s license number, and so forth. UII may include usernames, passwords, email addresses, instant messaging information, biometric information, medical information, and/or any other information that may be used to identify a person. 
     Variable verification will now be discussed in further detail. Referring back to  FIGS. 7 and 8 , there is shown a variable verification procedure  800  in which multiple verification factors  710  contribute respective amounts of verification strength (magnitudes  720 ) to produce an overall verification strength  830 , which the vault  140  may generate as a sum of verification strengths  720  of the respective factors  710 . The variable verification procedure  800  is performed in response to a right request  194 , which in the present example correspond to a request to access UII (i.e., an “access request”) of a user, such as the user  102  ( FIG. 1 ). 
       FIG. 16  shows additional features of certain verification factors  710 . Here, a verification factor  710   x , which may be representative of one or more of the verification factors  710 , is seen to have an upper bound  1610 , a lower bound  1620 , and an assigned level  1630 . The distance between the upper bound  1610  and the lower bound  1620  defines a range of possible values of the assigned level  1630 . Although the upper bound  1610  is greater (more positive) than the lower bound  1620 , there are no other restrictions on the values of upper bound  1610  and lower bound  1620 . For example, the lower bound  1620  may be zero, or even negative. A zero value of assigned level  1630  means that the respective authentication factor contributes nothing to overall verification strength  830 , whereas a negative value means that the respective authentication factor subtracts from overall verification strength  830 . A positive value adds to overall verification strength  830 . The vault  140  establishes assigned levels  1630  for verification factors based on testing, e.g., by testing received UPIDs, Device IDs, and so forth against values stored in the vault  140 , by measuring verification factors and comparing them with expected values, and/or by using other techniques. 
     Negative values of a lower bound  1620  may come into play, for example, when using location of a requestor device as a verification factor. For example, certain embodiments may employ an LPS (local positioning service) coupled to the vault  140 . The LPS is configured to measure locations of wireless-emitting devices and to maintain a map of the local environment surrounding the vault  140 . For example, the LPS establishes an LPS zone, which has clearly defined boundaries. If the LPS measures the location of the requesting device to be within the LPS zone, then the vault  140  may establish a positive value for a location-based verification factor  710   x . However, if the LPS fails to measure a location of the requesting device, e.g., if the device is roaming, the vault  140  may establish a negative value for the location-based verification factor. In this fashion, location of the requestor acts as a strong verification factor. Additional information about LPS systems may be found in copending U.S. patent application Ser. No. 15/452,451, filed Mar. 7, 2017, the contents and teachings of which are incorporated herein by reference. 
     One should appreciate that the terms “higher,” “lower,” “positive,” and “negative” are intended herein in a relative rather than absolute sense. For example, one could reverse the sign of the entire reference frame, such that “higher” could correspond to a negative number of greater absolute value while “lower” could correspond to a negative number of lesser absolute value. A “higher” bound would continue to be interpreted herein as the greater value even though it might be lesser than a “lower” bound in absolute terms. 
     Some verification factors for accessing certain elements of UII may be mandatory, meaning that a failure of a mandatory verification factor to match an expected value causes the verification operation  800  to fail, regardless of how well other verification factors match expected values. This arrangement is shown in  FIG. 8 , where a failure to satisfy mandatory factors  710   a  directly results in verification failure  860 . Examples of mandatory verification factors  710   a  may include UPID and Device ID. 
     As further described in connection with  FIG. 7 , the hierarchical vault password  512  ( FIG. 5 ) may itself provide a variable amount of verification strength. For example, an access request providing a smaller number of characters of the hierarchical vault password  512  provides less verification strength than one providing a larger number of characters. 
     In some examples, the verification factors  710  for accessing particular UII, the upper bounds  1610 , lower bounds  1620 , and verification thresholds  730 , are user-established and/or user-adjustable. For example, users can vary any of these settings to suit their particular needs for privacy in the UII and for balancing privacy against convenience. 
     As described in connection with  FIG. 1 , the vault  140  may securely store Device IDs  162   b  of devices and other electronic equipment that have been registered with the vault  140 . In an example, each registered device shares a pair of deep blind secrets with the vault  140 , which operate in a similar manner to the deep blind associate vault identifier  370  and deep blind associative VNS identifier  380  described in connection with  FIG. 3 . Using these pairs of deep blind secrets, a hierarchy of trust is established between devices and vault, and between vaults and VNS. 
       FIG. 17  shows an example of this hierarchy of trust in the form of a tree. Each node in the tree is an identified component of the vault network. Each connection in the tree is a bilateral secret that binds the two connected objects into a trusted relationship. Conceptually, any node on the tree can verify identity and vault network membership with any other node on the tree by following a chain of trust from source to destination. This does not imply that subsequent communication between the nodes would necessarily be over the same chain, however. 
     Additional features regarding the release of UII will now be described in further detail. Referring back to  FIG. 1 , device  110  initiates communication with the vault  140  by issuing a connection request  190  (also called an “introduction request”) to the vault  140 . The connection request  190  specifies the UPID of the user  102  and the Device ID, both of which the device  110  previously obtained from the vault  140 , in accordance with the trust hierarchy of  FIG. 17 . 
     The vault  140 , upon receiving the connection request  190 , compares the received UPID and Device ID with previously stored values (e.g., user IDs  162   a  and device IDs  162   b ). If both the UPID and Device ID from the request  190  match corresponding values stored in the vault  140 , a secure, point-to-point connection  192  is established between the device  110  and the vault  140 . Once the connection  192  is established, the device  110  may send an access request for UII in the form of a right-request  194 . Upon receiving the access request, the vault  140  performs the above-described variable verification procedure  800  and determines whether or not to release the requested UII to the requestor device  110 , based on the results of variable verification. 
     One should appreciate that similar acts may be performed when the device  110  is remote. Indeed, a similar protocol may be used when the vault  140  is contacted by any computerized apparatus, such as some other device, server, or other vault. 
     Introductions: 
     As indicated previously, the vault network is a closed network that does not normally permit communication between different users except via established communication rights. The vault network employs the concept of “introductions” to establish such communication rights. Communication rights may be established between users of different vaults and/or between users of the same vault. The UPID Name Server (UNS)  240  performs a central role in facilitating introductions between users, as it associates UPIDs of users in the vault network with corresponding vault IDs  312  ( FIG. 3 ) of home vaults operated by the users holding those UPIDs. Various types of introductions will now be described. 
     Bootstrapping Existing Communications 
     Legacy communication types have the potential to be promoted to vault network communication. A communication client may be modified to handle a vault network version of a communication service, thus making the communication vault aware. Using an existing communication method, a request along with the UPID of the requestor is sent to the receiver. The requestor&#39;s Home Vault ID is not sent. If the receiver chooses to accept the request, it looks up the home vault on the UNS  240  and then contacts that home vault to ensure that the request is legitimate. 
     As stated previously, vault network is closed, and the UPID is not intended to be exposed outside of the vault network. A vault aware communication client (that is going to support promotion to the vault network) must be backwards compatible with the associated legacy service, so it must have the ability to detect if the opposing side is vault aware, as well. 
       FIG. 18  shows an example protocol of a complete introduction process including the verification of the client. In broad summary, the protocol of  FIG. 18  establishes a communication right between a first user and a second user by (i) receiving, from the device of the second user, a UPID of the second user, (ii) contacting the UNS  240  to identify the home vault of the second user, (iii) establishing communication over the computer network between the home vault of the first user and the home vault of the second user to obtain user information from the home vault of the second user, and (iv) storing the user information from the home vault of the second user in the communication right in the home vault of the first user. The activities depicted in  FIG. 18  are as follows:
         InroRequest: Client 1 asks for an introduction request from its vault. The introduction request will identify the UPID of the user of Client 1.   InroCodeRequest(UPID1): Vault 1 asks for an introduction request code for user UPID1. User UPID1 must be member of the calling vault.   IntroCode(Code1): The UNS responds back with a introduction code, Code1, that maps to UPID1. A valid vault can use this code to find the UPID. The code is worthless to anything other than a valid vault.   IntroReply(Code1): Vault 1 passes the code to Client 1.   IntroductionOffer(Code1): Client 1 and Client 2 are both Vault Aware clients of a legacy communication system. This means that the messages they send to each other are legacy messages and not protected by the vault network. This why a code is used rather transferring a UPID. The vault network has no method to guarantee the UPID is not skimmed from the legacy communication. The code on the other is useless to a skimmer. The vault that retrieves the code is logged. If at the end of this protocol the intended recipient, Client 2&#39;s vault, does not use the code, then the vault that does is flagged with a protocol error and kicked out of the vault network.   IntroOffer(Code1): Client 2 passes the code to its vault.   UPIDCodeRequest(Code1): Vault 2 asks for the code to be converted to a UPID and Home Vault.   CodeResponse(UPID1,VID1): The UNS responds back with the corresponding UPID and Home Vault.   GetPublicKey(VID1): Vault 2 asks for the contact information for Vault 1.   PublicKey(VID1,K1pu,VNA1): VNS replies with public key and vault network address.   K1pu[VaultToVaultConnect(VID2,RN,Ksvv)]: Vault 2 starts a secure session with Vault 1. The focus of explaining these protocols is not the encryption. This one is shown for clarity only.   GetPublicKey(VID2): Vault 1 turns around and get contact info of Vault 2 with the VNS.   PublicKey(VID2,K2pu,VNA2): Vault 1 receives contact info Vault 2.   VerifyVault(RN,K2pu[RN2]): Vault 1 responds back with RN to prove its identity and asks Vault 2 to prove its identity.   OutofBandIntroReply(RN2,Code1,UPID1): Vault 2 knows after checking with the core servers that Vault 1 is the requester of the introduction for UPID1. Hence Vault sends its response back to Vault 1.   VerifyApplication(AID1): Vault 1 one asks Vault 2 to verify its Client Application.   VerifyApplication(AID1,UPID1): Vault 2 asks the Classification Server if the Application is valid.   ApplcationVerified: Classification Server responds back that application is valid.   VerifyAppAndIntroUser(AID2,UPID2): Now Vault 2 introduces the connected user to Vault 1. Vault 1 did not know UPID2 before because the communication UPID1 and UPID2 shared was legacy and hence hidden to the vault network.   VerifyApplication(AID2,UPID2): Vault 1 verifies the Client Application of UPID2.   ApplicationVerified: Classification Server states application is valid.   CRRequest(CRData1): Vault 1 sends a Communication Right request to Vault 2 with the corresponding right data.   CRReply(CRData2): Vault 2 responds back, accepting the request and supplying its data to complete the data required for the creation of the Communication Right.   IntroSuccessful: Vault 1 tells Client 1 that the introduction was successful.   Ack: Client 1 acknowledges success to Vault 1   Ack: Vault 1 acknowledges success to Vault 2.   IntroSuccessful: Vault 2 informs Client 2 that introduction was successful, i.e. Communication Right created.   LegacyConfirm: Client 2 confirms to Client 1 over the legacy communication method that the Communication Right was successfully created.
 
Device to Device
       

     It is exceedingly common for people to carry a mobile device. It only makes sense that they would like an extremely simple method to exchange contact information with those devices. The Device to Device Secure Private Introduction Protocol makes full use of the unique capabilities of a mobile device connected to the vault network. 
     The Device to Device Secure Private Introduction Protocol is based on the notion that if two people are physically close to each other, they can see each other. The protocol presents no information about an unknown person other that what the user can see with his or her own eyes. 
     The protocol runs as an application on a mobile device. By opening the application, the Virtual Model of the public portion of the local LPS Zone is displayed as a map to the user. If the user is moving, the movement may be used to create an orientation vector to correctly display the orientation of the map. If the user is not moving, the user can purposely orients the map using simple controls within the app combined with movement of the device. Other people in the LPS Zone may also run the app on their mobile devices. These other people will show up on the user&#39;s app. 
       FIG. 19  shows a simple diagram of a display of the app, as it would appear to a user of a mobile device. Here, app display  1900  shows a map  1910  of a physical space in the vicinity of the user, as rendered by a local LPS system coupled to a local vault. Optional orientation arrows  1912  and a map orientation button  1914  may be provided to assist the user in visualizing the space. The space can be seen to have walls or other obstructions  1920 , as well as a table  1930 . The amount of detail shown in the map  1910  may be specified by the owner of the local vault. 
     In the example shown, which is intended merely to be illustrative, shaded circles and crosses represent people within the space. Circles may be color-coded for user convenience, or distinguished in some other way to indicate different status. In addition, icons other than circles and crosses may be used. As an example, a green circle may represent the current user. Blue circles represent connected users logged on to the service, where a “connected user” is one who already shares a communication right with the current user. Purple circles indicate connected users logged on to the service but out of visual range or blocked from view. Yellow circles represent non-connected users (who do not share a communication right with the current user) logged onto the service. Crosses represent non-connected users logged on to the service, but who are not shown to the current user because they are out or range or blocked from view. 
     As indicated, yellow circles represent people who are logged into the application, in view of the user, and not presently sharing a communication with the user. In an example, the user clicks on one of the yellow circle icons and the application responds by showing a photograph of that person (provided by that person as part of their user profile). The current user now has two pieces of information to ensure that the person is the correct target for an introduction request: the person&#39;s location on the map relative to the current user and the photo of the person. 
     Providing a photo for verification is not a violation of that person&#39;s privacy because they are already being seen. There is no need for a name to be included with the photo as visual verification is sufficient. 
     Going back to the protocol, after selecting the icon and seeing the picture verification, the current user clicks the picture. The app then notifies the other person. On the other person&#39;s app they see a picture next to the current user&#39;s icon. The person accepts by clicking the user&#39;s picture. The two now share a communication right together. 
     Universal Keys and Other Mobile Devices 
     Users may wish to make introductions using small, handheld devices. One such device is a Universal Key as described in copending U.S. application Ser. No. 15/790,440, filed Oct. 23, 2017, which is hereby incorporated by reference. 
     Introduction using a Universal Key is similar to that involving bootstrapping legacy communication because of the use of a code on the UNS  240  that convert from the code to a UPID. It is also similar because it is the user&#39;s home vault that is directly inserting those codes onto the UNS  240 . The difference is the time of life for the codes on the UNS  240 . In the bootstrapping case, a code is claimed almost immediately after creation. In the Universal Key case, the home vault inserts a code into both the UNS  240  and Universal Key. At same later time, the Universal Key passes this code to another Universal Key. The code is not claimed on the UNS until that second Universal Key goes home and connects to its home vault. 
       FIG. 20  shows an example arrangement for mating a first Universal Key  2010  of a first user with a second Universal Key  2020  of a second user. Each Universal Key has an optical interface that mates with a similarly arranged optical interface on the other Universal Key. To establish an introduction, two users mate their Universal Keys as shown, and the user of each Universal Key presses a button to release a code to the other Universal Key. Later, once contact is made with the respective home vaults, the Universal Keys initiate the completion of the introduction process. A communication right is not created until both sides have confirmed. 
     Introductions via Universal Keys are intended to prevent leakage of UPIDs from the vault network. When two universal keys are used for an introduction, there are no vaults involved during initial contact; hence, there is no way for a universal key to verify the recipient. 
       FIG. 21  shows an example protocol for establishing a communication right via a pair of Universal Keys or similarly configured mobile devices. The illustrated protocol assumes that a Universal Key has already been given a user introduction code from another user, via the exchange described above. As an example, we use the trigger to claim user introduction code to be the placement of the Universal Key into a docking station. As both users had to push a button on their keys to initiate the transfer, the creation of the communication right between the two users is authorized at that time. Either user may initiate the creation. To create the right, the default permissions of both sides are compared and the least permissive choice of each field of the right is chosen. The users may always request to change the permissions at a later time if desired. 
     The introduction protocol as shown in  FIG. 21  involves the following acts:
         Dock: This is not a message per se; it is an action that the user takes.   IntroRequest(UIC): Upon being docked the Universal Key sends its vault any user introduction codes it might have, in this case UIC.   CRInvitationRequest(UIC): Vault 2 had already previously set up the UIC in the UNS. Note that is different than in the legacy communications case where the code is created and then used in near real time. In this case each vault preloads UICs onto the Universal Keys and UNS and then at a later date they are used.   UserInformation(VID2,UPID2): The user information for the given code is only sent to a valid vault.   GetPublicKey(VID2): Vault 1 asks for the contact information for Vault 2.   PublicKey(VID2,K2pu,VNA2): Standard reply   VaultToVaultConnect(RN,VID1,Ksvv): Standard connect request   GetPublicKey(VID1): Standard verification of vault.   PublicKey(VID1,K1pu,VNA1): Get contact info.   VaultVerify(RN,K1pu[RN2]): Verify the vault.   CRCreateRequest(RN2,CRDefaults,UPID1,UPID2,UIC): Vault 1 requests the creation of a Communication Right between UPID1 and UPID2. The UIC is sent to verify to Vault 2 that this is a valid request that Vault 2 had previously authorized.   GetHomeVault(UPID1): Vault 2 makes sure that Vault 1 is the Home Vault of UPID1.   HomeVault(UPID1,VID1): Vault 2 receives confirmation.   CRCreateResponse(CRData,UPID1,UPID2): Vault 2 responds back with data necessary to complete creation of the Communication Right   CreateCR(CRData,UPID1,UPID2): Vault 1 responds back that the right has been created with the confirmed data.   Ack: Vault 2 acknowledges creation of right.
 
Business Cards, QR Codes, and the Like
       

     The vault network supports introductions using business cards. Preferably, a business card should not directly contain a UPID; otherwise, leakage of UPIDs from the vault network could occur. Rather than providing a UPID, the business card contains a code, embedded in a scannable image, which permits the receiver of the business card to send an introduction request to the grantor of the business card without ever knowing the UPID of the grantor. Whether or not the communication right is automatically created when the user scans the card is up to the grantor of the card. At the time of card creation, the grantor decides whether the communication right should be created immediately or if creation should wait for approval. If the grantor demands to approve right creation before it is created, the receiver of the card must decide what information she is willing to share to prove she is the person who received the card. A very common option for proof such as this would be the card receiver&#39;s profile picture. 
       FIG. 22  shows an example protocol for introductions using business cards. In broad summary, the process involves providing, by a first user, a scannable image, such as a QR code, bar code, or the like. When scanned, the scannable image provides data that enables a device of a second user to send a connection request to the home vault of the first user to request a communication right with the first user. The connection request sent by the second user includes a UPID of the second user. In an example, the data encoded in the scannable image includes a code that the UNS  240  associates with the UPID and home vault of the first user. Although the illustrated example applies to business cards, one should appreciate that the same process may apply to flyers, posts, or any exchanged medium, whether tangible or electronic. 
     In the case of  FIG. 22 , the grantor is required to give his approval. In an automatic creation case, the process would follow the same process as the Universal Key.  FIG. 22  shows the following acts:
         ScanCard(BC): User uses device to scan business card BC.   ScanSuccessful: Device responds that scan was successful.   SendIntroductionRequest: User instructs device to send the introduction request.   CRIntroductionRequest(UIC): The device sends the scanned user introduction code, UIC, to the vault.   CRIntroductionRequest(UIC): The vault forwards the introduction request to the UNS.   UserInformation(VID2,UPID2): The UNS determines that the UIC is valid and responds back with the UPID and Home Vault VID of that UPID. If this is a single use UIC then the UNS will not respond to another request.   GetPublicKey(VID2): The vault request the contact info for the other user&#39;s Home Vault.   PublicKey(VID2,K2pu,VNA2): VNS responds back with contact info.   K2pu[VaultToVaultConnect(VID1,RN,Ksvv): Standard connect.   GetPublicKey(VID1): Vault 2 requests the contact information of the requestor from the VNS.   PublicKey(VID1,K2pu,VNA1): VNS responds back with connection information   VaultVerify(RN,K2pu[RN2]): Standard vault verification.   RetieveCRInfo(RN2,UPID1,UPID2,UIC): Vault 1 requests Communication Right information for the offered Communication Right. Vault 1 informs Vault 2 that UPID1 is the requesting user.   GetHomeVault(UPID1): Vault 2 checks to make sure that Vault 1 is the Home Vault of UPID1.   HomeVault(UPID1,VID1): Check is satisfied.   CRInfo(CRData,UPID1,UPID2): Vault 2 sends Communication Right data to Vault 1.   CRInfo(CRData,UPID2): Vault 1 sends pertinent data to Device 1 so.   CRInfo(CRData,User2): Device 1 shows user friendly data such as name and/or thumbnail picture to user 1 for verification.   CRApproved: User 1 approves.   CRApproved: Device forwards approval to Vault 1.   CRApproved(CRData,User1Data): Vault 1 responds back confirming the data sent to it and include necessary information from user 1.   ApproveCRToUser(User1Data): This and the next 3 messages are optional. The purpose is for user 2 to approve the Communication Right. The type of Business Card given to user 1 determines whether the acceptance is automatic or needs approval from user 2.   ApproveCRToUser(User1Data): Device passes user friendly data to user 2. This may include user 1 name and/or thumbnail picture.   CRApprove: User 2 approves.   CRAppove: Device forwards approval. End of optional portion.   CreateCR(CRData,UPID1,UPID2): Vault 2 creates its half of the Communication Right and informs vault 1 to the same. The rest of the messages are just notifications and acknowledgments that the CR was created.
 
Asserting and Tracking Identity:
       

     It is sometimes desirable for individuals and organizations to present provable expressions of their own identity. For example, a person may wish to associate him or herself unambiguously with a particular statement made online, such as a blog post, comment, online petition, or news article. In the current times of alleged fake news, the ability to provably identify sources is paramount. 
     The vault network naturally lends itself to the capacity to prove identity. For example, each user of the vault network has one and only one UPID. Although it may be possible for a user to change UPID (e.g., if one is lost), such changes are expected to be rare, are tracked by the vault network, and may indeed be burdensome to users. This being the case, UPIDs provide an effective vehicle for tracking user activity. 
     Unlike conventional schemes, where users identify themselves based on user names only and may have different user names on different sites, users of vault-aware websites establish communication rights using their UPIDs. Thus, any vault-aware site on which a user communicates has that user&#39;s UPID. The UPID serves not only as a mechanism for identifying the user personally, but also provides a common identifier that applies across different sites, allowing users to be easily tracked. 
     Ease of tracking provides benefits to both organizations and users. Organizations can employ UPIDs to police bad actors. For example, if a user is banned from a particular vault-aware forum, the forum can block the same user from trying to log on again under a new user name, as each request to create a new account would require the user to disclose his or her UPID, thus triggering detection of the banned user and preventing the new account creation. Users also benefit from this ease of tracking. For example, a user can share his or her own identity information among different on-line sites. The user might have a reputation score on one site and wish to have it known on another site. The common use of UPIDs among different sites enables reputation scores of users to be shared through vault-aware applications. 
     “Identity association” is the ability for a user to associate his identity to another object. In the case of a device, this is accomplished with the above-described Deep Blind Secrets that bind the device to the user and the user&#39;s home vault. 
     In the case of content, a user associates his or her identity through the use of identifiers and digital signatures. For a content right, the header of the file contains the UPID of the owner. The entire file is then digitally signed. The signature can be verified by the claimed user&#39;s vault to ensure that the signature is valid and the content is owned by the claimed party. A hacker cannot modify the file in any way without detection. The only hack possible is to replace the UPID and the digital signature, but that would serve no purpose for the hacker. 
     The same concept is generalizable in the vault network. Inside a vault-aware application, a user may sign any portion of the data that the application stores. Other users within the application can then verify that the claimed user actually signed the content. The purpose of signing content in this manner is not merely to claim ownership as in the content right, but also to allow users to make statements about content within the vault aware application that are verifiable. The idea is further generalizable to users making statements about the relationship between two or more objects used in a vault aware application. 
       FIG. 23  shows an example of how a statement may be associated with a relation of objects. A simple example is as follows. One user writes an opinion article. Another user comes along and makes a statement such as, “I believe this opinion is correct because of these sources.” The user&#39;s statement is verifiably bound to immutable copies of the opinion article as well as the sources. 
     For these types of statements, only the Content is required. Related Content is optional. The Statement is typically text that represents the opinion of the user. The UPID is that of the Statement maker. All the signatures are created by the user. A purpose of this method is to help form the basis of vault aware application user reputation systems. 
     The goal of digital signatures being used in this manner is not necessarily to replace trusted third party signing authorities. The goal is to make the user&#39;s home vault a signing authority for that user. This type of signing will be appropriate for certain applications, and trusted third party signing will be appropriate for other applications. In an example, to reduce the load on the vault in terms of requests for checking the signature, the vault gives the vault aware application the key to check signatures, and the vault aware application can then disperse the proper key as required. The vault retains the key used to make the signatures. This key is shared only with the user&#39;s device in order to calculate the signature for the content to which the device has visibility. 
     To this end, the home vault  140  of the user includes executable instructions to operate the home vault  140  as a personal signing authority for the user. The personal signing authority operative in the vault  140  associates digital signatures applied by the user with the UPID of the user. Users may apply digital signatures to any desired content, which may include, without limitation, forum posts, comments posted in a comments section of a website, and news stories. 
       FIG. 24  shows an example method  2400  that may be carried out in connection with the environment  100 . The method  2400  is typically performed, for example, by the software constructs described in connection with  FIG. 1 , which reside, at least in part, in the memory  150  and  160  of the vault appliance  140  and are run by the set of processing units  144 . The various acts of method  2400  may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in orders different from that illustrated, which may include performing some acts simultaneously. 
     At  2410 , a set of UII (e.g., any of information  610 ) of a user  102  and (ii) a verification threshold  730  that defines a total verification strength needed for accessing the set of UII of the user are stored in non-volatile memory  160  of a hardware appliance (e.g., vault  140 ). 
     At  2420 , the hardware appliance  140  receives from a requestor (e.g., device  110 ), an access request  194  to access the set of UII  610  stored in the hardware appliance  140 . 
     At  2430 , in response to receiving the access request  194 , the hardware appliance  140  performs a verification operation  800 , the verification operation  800  ( i ) tests multiple verification factors  710  associated with the access request  194 , (ii) produces, for each verification factor  710 , a respective verification strength  720 , (iii) combines the respective verification strengths to produce an overall result  830 , and (iv) compares the overall result with the verification threshold  730 . 
     The verification operation  800  then selectively releases the set of UII  610  to the requestor  110  in response to the overall result  830  exceeding the verification threshold  730 , or blocks the set of UII  610  from being released to the requestor  110  in response to the overall result  830  falling below the verification threshold  730 . 
     An improved technique has been described for promoting network security. The technique employs a user-centric approach in which a hardware appliance  140  serves as a local security hub for storing and dispatching user identity information (UII). The hardware appliance  140  is configured to release UII in response to access requests by applying a variable verification procedure  800 . The variable verification procedure  800  tests multiple verification factors  710  associated with an access request  194 , assigns a verification strength  720  to each factor, and selectively releases the requested UII in response to a combined verification strength  830  exceeding a threshold  730 . 
     Having described certain embodiments, numerous alternative embodiments or variations can be made. For example, although embodiments have been shown and described in connection with a vault  140 , which is presented with a specifically-defined structure, embodiments hereof should not be construed as requiring all of the disclosed features of the vault  140 . Rather, any hardware appliance that meets the requirements as recited in the respective claims below would suffice. 
     Further, although features are shown and described with reference to particular embodiments hereof, such features may be included and hereby are included in any of the disclosed embodiments and their variants. Thus, it is understood that features disclosed in connection with any embodiment are included as variants of any other embodiment. 
     Further still, the improvement or portions thereof may be embodied as a computer program product including one or more non-transient, computer-readable storage media, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash drive, solid state drive, SD (Secure Digital) chip or device, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and/or the like (shown by way of example as medium  1550  in  FIGS. 15 and 24 ). Any number of computer-readable media may be used. The media may be encoded with instructions which, when executed on one or more computers or other processors, perform the process or processes described herein. Such media may be considered articles of manufacture or machines, and may be transportable from one machine to another. 
     As used throughout this document, the words “comprising,” “including,” “containing,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Also, as used herein and unless a specific statement is made to the contrary, the word “set” means one or more of something. This is the case regardless of whether the phrase “set of” is followed by a singular or plural object and regardless of whether it is conjugated with a singular or plural verb. Further, although ordinal expressions, such as “first,” “second,” “third,” and so on, may be used as adjectives herein, such ordinal expressions are used for identification purposes and, unless specifically indicated, are not intended to imply any ordering or sequence. Thus, for example, a second event may take place before or after a first event, or even if no first event ever occurs. In addition, an identification herein of a particular element, feature, or act as being a “first” such element, feature, or act should not be construed as requiring that there must also be a “second” or other such element, feature or act. Rather, the “first” item may be the only one. Although certain embodiments are disclosed herein, it is understood that these are provided by way of example only and that the invention is not limited to these particular embodiments. 
     Further, the foregoing description provides workable examples of security improvements, but such examples are not intended to be limiting. For instance, when describing certain security features, certain words and phrases that normally denote absolutes, such as “never,” “always,” “must,” and the like, are presented in the spirit of defining a rules-governed system that is secure. Actual implementations of the disclosed embodiments permit there to be exceptions, however, e.g., for special cases or where diminished security is acceptable. Any absolute statements made herein are therefore intended to describe ideal or optimal conditions. Such conditions may be consistent with design intent for a perfectly secure system, but they are not intended to impose limitations on any eventual embodiments or on the claims that follow. 
     Those skilled in the art will therefore understand that various changes in form and detail may be made to the embodiments disclosed herein without departing from the scope of the invention.