Patent Application
20160088474
Embodiments relate to pairing and authentication operations on computing devices using motion information obtained from one or more users.
Ad-hoc networks are typically formed when computing devices such as mobile devices seek to interact. In some scenarios, information regarding the ad-hoc interactions may be remembered in anticipation of subsequent ad-hoc interactions, possibly in a different location but involving the same devices discovered during the first ad-hoc interaction.
Secure ad-hoc interactions may require device pairing and user authentication to be accomplished using ad-hoc means. Traditional methods for device pairing and user authentication often involve a trusted third party that pre-registered and enrolled devices and users. However, such trusted third party approaches do not scale in ad-hoc environments.
In various embodiments, one or more sensors of multiple computing devices, e.g., motion sensors, may be used to establish highly entropic device pairing and user authentication reference templates. Embodiments may combine the process of device pairing with user authentication training Such operations may be particularly applicable to the so-called step zero problem in cryptographic systems. Data obtained from sensors provide context for authentication during training (by one or multiple users) to a plurality of classifiers, including a first classifier to generate shared entropic values (which may be used to pair devices) and one or more other classifiers to generate biometric templates (which may be used for user authentication).
Still further, even greater security and trust properties may be provided by way of a trusted execution environment (TEE) established in the devices. Understand also that the pairing and authentication protocols described herein may be performed without the presence of a trusted third party such as a certificate authority in accordance with a public key infrastructure (PKI). This is so, as context information associated with pairing and authentication processes assume the role of the third party authority.
The keys generated herein, referred to as relationship pairing keys (RPKs), have cryptographic properties and may be used in various embodiments without the need for interaction with a trusted third party (such as a certificate authority (CA) to confirm context surrounding association/binding of key to person. Instead, embodiments provide context directly by way of biometric-based motion context to authenticate a user. This authentication context can be associated with the RPK keys by the TEE. The TEE binding of RPKs to context values effectively performs the operations of a PKI Registration Authority (RA) and Certificate Authority (CA), and thus without use of the infrastructure of conventional PKI methods.
Ad-hoc network interactions are often prefaced by in-person interactions. Such interactions can support secure communications thereafter if a key exchange operation is performed at the point of the interaction. In various embodiments, exchanged keys may capture in-person context sufficiently to enable users to recognize the trust semantics that exist surrounding the keys. In an embodiment, these trust semantics may include an ability to authenticate both the person and the device that performed the in-person interaction.
Although the scope of the present invention is not limited in this regard, embodiments may leverage a variety of sensors and other components that are commonly available in mobile devices. In one example, motion sensors (e.g., 6-axis or 9-axis sensors) may be used to obtain biometric input such as user movement and gesture recognition. To this end during an in-person interaction between two users each having a mobile device that the users desire to pair for purposes of device-to-device communication (e.g., while the devices are located locally with each other or remotely), both users in turn hold both devices and perform one or more (e.g., a series) of typical (for the user), prescribed or random movements to provide training data to both devices simultaneously.
Training initially involves capturing sensor readings and associating the captured sensor information with a corresponding device identifier for the device and a user identifier for the user. If the users have previously been authenticated to the device, then the current user's authentication state may also be associated with the capture. In an embodiment, both users perform training by performing the motion training using both devices. Multiple classifiers, which are configured to extract information useful for secure reconstruction of the in-person interaction while the key exchange is performed, then process the collected samples. Note that this sample data produces a pseudo-random number, which can then be used to perform symmetric encryption or for authentication purposes.
Key exchange may involve use of a symmetric key exchange protocol (e.g., Diffie-Hellman) to construct a secure channel over which additional keys (such as Rivest Shamir Adleman (RSA) public/private key pairs) may be exchanged, along with at least certain attribute information derived by the separate classifiers.
In turn, both devices can authenticate the in-person interaction context by comparing the resultant values, e.g., using compare functions that satisfy an acceptable error rate. A function that produces a shared entropic value may be used to align the first and second entropic values, and discard bits that do not match according to a bi-conditional logic (e.g., if !XOR(a, b)=1, else 0), where a and b are a given user's samples obtained from the 2 different devices). Note that the compare function may reduce the axes of the sample data (e.g., from x, y, z to magnitude) and use a time-based correlation function to mutually align to the most likely starting point in each signal. In one embodiment, this NOT XOR operation is a way to combine two sets of motion data into one.
The motion sensors on both devices are thus used to create a device pairing identifier (device ID) for a given user (and associated with that user's device) based on that user's biomechanics. The NOT XOR operation may be performed on received motion sensor data in a bitwise fashion to smooth the data. If a given bit in the bitstream agrees between the motion sample data from both devices, then a TRUE (logic 1) is output, otherwise a FALSE (logic 0) is output. If the ratio of TRUE to FALSE bits approaches 1, then the device ID is acceptable. If it approaches 0, then it is unacceptable. A threshold policy can be used to determine where to draw the line. In different embodiments, a device ID value may be generated using either A or B actual sensor input, or the actual sensor input data can be combined using a secure hash algorithm to produce a value that is an amalgamation of both. Embodiments thus may use a NOT XOR operation (or similar operation) as a smoothing function with a threshold mechanism controllable by policy to enable a user to specify how accurate/lenient motion-based authentication is to be.
In turn, a biometric authentication function may be used to produce a reference template from the collected training data, where the sample collected from a first user produces a reference biometric template suitable for authenticating the first user within a certain confidence rate. The sample collected from a second user produces a reference biometric template suitable for authenticating the second user within a certain confidence rate. Note also in an embodiment, axis reduction may be applied to eliminate specific orientation of one or both devices. Further, in an embodiment, a correlation function may be applied to align the most likely starting point of two asserted signals. In an embodiment, the reference template and acceptable confidence threshold value are used to compare a contemporary sample that satisfies the confidence threshold as part of an authentication challenge.
In some embodiments, date and time and/or other context information (such as location of the in-person interaction) may be used in computation of a device ID to increase entropy and to further disambiguate the pairing event. If a pairing event stipulates for proof that a human performed the pairing to avoid accidental pairing (for example when devices are in the glove compartment of the same car), the users can be caused to perform a specific action to demonstrate mutual intention. For example, the pairing operation may require both users to simultaneously perform a given swipe pattern on a touch screen of their mobile devices. In such cases, these swipe results are shared with the opposite device and included in the device ID computation. In some embodiments, accidental pairing may be prevented by such simultaneous touch operation.
Referring now to
As shown, first portable device 110 includes a security logic 115, which in various embodiments may be implemented as a standalone processor or security logic within a general-purpose processor such as a system on a chip (SoC) of the device. Of course many other implementations of security logic to perform a motion-based pairing as described herein are possible in other embodiments. As further illustrated, first portable device 110 further includes a storage 118, which may be configured as a volatile or non-volatile storage of the device. In various embodiments, storage 118 may include a relationship database including a relationship entry for the pairing between device 110 other devices. Illustrated in
As will be described further herein, a motion-based pairing protocol may be performed between the devices to enable receipt of training data regarding each of the user's independent training of both devices. Based on this training information obtained during a training phase, a relationship pairing key may be generated, along with a confidence value regarding a relative match between the user/owner of the local device's motion sample during training and a reference motion template previously stored by the user/owner.
When the first and second users (“Alice” and “Bob”) meet in person, motion and/or other sensors on both devices collect sample data that can be used to both pair the devices (for generation of device keys) and pair the users using a digital relationship context for exchanging relationship keys. Note that this initial key exchange may have some amount of variance or noise (after sample data reduction and correlation), given that in many embodiments this initial key may only be used for purposes of performing an initial pairing and deriving asymmetric keys. However the strength of this initial key exchange is sufficient to prevent replay and socialization attacks. Note that such negotiated asymmetric key pair may be later used to authenticate the users and create a secure channel between devices.
After both users perform a brief training exercise in which both devices receive training data from both users, the devices may subsequently authenticate the users when they are no longer physically present in the same location. In an embodiment, the sample data may be compared to a motion factor reference template (e.g., previously generated based on earlier user input) to compute an error value corresponding to the differential between the high quality reference template and the trained sample. An expected or threshold error value may be shared during relationship pairing. Note that suggested error thresholds may be automatically produced based on the error measured during situations when both devices are known to be moved together.
In the high-level view of the protocol shown in
Referring now to
As seen, method 200 begins during an interaction between users at block 205 where a first user is provided with the mobile device of the other user such that this first user has possession of both mobile devices, e.g., handheld one on top of another in the first user's hand. Note that during the operations, an application such as a sharing application may be active on both devices, which may direct the various user training operations and the corresponding pairing operations to be performed by the hardware of the devices. The motion-based training begins at block 210 where the user performs a motion that is thus common to both portable devices. As examples, the user may hold, carry and/or shake the devices simultaneously. The users may assume orientation of axis between the two devices does not matter for training purposes. This may be so, as embodiments may perform axis translation functions that normalize sensor data (e.g., motion reading accelerometer, gyrometer and magnetometer) along each axis to account for common orientation combinations including front-front, front-back, back-back, top-top, top-bottom. Additionally, spectral analysis may include magnitude and phase information analysis for similarity over multiple axes.
Responsive to such motion, at block 215 motion samples are stored on each of the devices and are associated with the given user. Many different types of motion sensors may be leveraged independently or collectively and may include any types of accelerometers, position sensing devices such as a global positioning system (GPS) sensor and so forth. In some embodiments, motion on multiple axes may be combined to form a magnitude function, eliminating the need to precisely align devices. Next control passes to diamond 220 to determine whether a bilateral user authentication is desired. If so, the first user provides both devices to the second user (block 225). As such, steps 210 and 215 may be iteratively performed by both users with both devices.
Still with reference to
Still referring to
Control next passes to block 245 where a relationship pairing key may be generated, e.g., as an asymmetric key pair. More specifically, this relationship pairing key may include a public key and a private key and may be generated based on independent random number systems. In other embodiments, the asymmetric keys can be derived based on a shared symmetric key. In one embodiment, this relationship pairing key may be generated as a RSA key pair or an elliptical curve key pair. Control next passes to block 250 where the authentication value and the relationship public key may be sent to the remote device, e.g., using the pairing key. In turn at block 255 the remote device receives these values and stores them in a corresponding entry of a relationship database for the relationship between the two computing devices and their users. Note further that additional information stored in this entry includes a local motion sample received in the second device responsive to the first user's interaction with that device during training phase and a corresponding relationship pairing key for that device (as determined in the second computing device during its training).
Then control passes to block 260 where the pairing process between the two devices is thus completed. Note of course that the same operations described above primarily with regard to the first device equally occur on the second computing device (and for the second user) so that the pairing may be established.
Still referring to
Control next passes to block 275 where the first user seeks second user input to perform an authentication motion. Note that this authentication motion may generally be similar to that which the second user performed during training so that the authentication may proceed correctly. This is the case, as users typically perform various motions with a high degree of similarity of movements such that a motion-based authentication can be performed in a highly secure manner.
After input of this motion information into the second device, the second device sends this motion sample to the first device (block 280). Next, control passes to block 285 where the first device compares this received motion sample to a stored remote motion sample. Control next passes to diamond 290 to determine whether there is a match to at least a threshold level. This comparison may include reducing axes (reduce x,y,z accelerations to a single acceleration magnitude signal) and correlating in time to identify the best possible mutual starting alignment point. In an embodiment, this determination may be made by a comparison between the two motion samples to determine whether the error rate between them is less than a threshold amount, which in an embodiment may correspond to the authentication value previously sent. If so, control passes next to diamond 295 to determine whether a bilateral user authentication is desired. If so, control passes back to block 275 discussed above. Otherwise or after the second such authentication, control passes to block 298 where continued collaboration may occur between devices. Note that prior to such continued collaboration, various communications may be encrypted, e.g., according to keys derived e.g., from the relationship pairing key structure. Further the scope of such communications or sharing may be controlled according to sharing policies of different users/devices. Understand while shown at this high level in the embodiment of
Referring now to
Thus as shown in
As seen, the motion sample information from both devices is provided to a device pairing classifier 312, which generates a device pairing value for the relationship between Alice and Bob (referred to as “Bob”). In an embodiment, both devices generate a common device pairing value for the relationship between the devices and users, and from this information and possibly additional information, including context information 315 (that in an embodiment includes location, date and time information, among other possibly sample context information) a device identifier is generated. Specifically, first device 310 generates a device identifier 313 associated with the second device, and vice versa (with second device 320 generating device identifier 323).
In device pairing phase 301, device pairing classifiers 312 and 322 may execute to generate a device pairing value based on user sample data (obtained from both devices) using the algorithm: if !XOR(a,b)=1→T; else →F, in an embodiment, and may further include axis reduction functions and time correlation to optimally match starting points. Note that if the length of the device pairing value is less than a threshold value (e.g., less than 256 bits), then the sensors did not produce enough similar values to justify device pairing, and thus pairing is terminated. In another embodiment, the device pairing classifiers may perform the XOR operation then select the local sample in the case of the local user or select the remote sample in the case of the remote user, where the ratio of logic ones to zeros resulting from the XOR operation exceeds a confidence threshold, e.g., a ratio greater than 90%.
In an embodiment, device IDs can be generated using a secure hash computation according to:
DevIDA=SHA256(motion value, “Alice”) and
DevIDB=SHA256(motion value, “Bob”).
In turn, these device IDs can be used to generate temporal keys that are used for data sharing between devices during a device authentication phase. Note in some embodiments, the Device ID computation may include context information 315 (e.g., location context) that fixes the pairing event to a specific place and time for further uniqueness of the pairing event. For example in such embodiments the device IDs may be computed as follows: (e.g., DevIDA=SHA256 (motion value, “Alice”, locationA, date-timeA, locationB, date-timeB)).
In still other embodiments, device ID computation may include assertion of user presence context based on a predetermined user input operation, such as the 2 users performing a set of simultaneous swipe operations on their respective devices. As one example, such simultaneous swipe may be achieved by computing the device ID in stages where the initial stage iteratively feeds an intermediate DeviceID into the computation. For example:
DevIDINITIAL=DevIDA;
DevID1=SHA256(DevIDINITIAL, swipe_motion—1);
DevID2=SHA256(DevIDINITIAL, swipe_motion—2);
DevID3=SHA256(DevIDINITIAL, swipe_motion—3).
This iterative process may continue until all swipe motions are completed. If both parties perform the same swipe motions correctly, then the device ID values will be equivalent. In this situation, subsequent device ID-based authentication protocols will fail if the device IDs differ.
As further shown as part of the pairing phase 301, the local sample information at block 311 is further provided to a motion authentication classifier 314, which further receives a motion factor reference template 316, which may be previously obtained motion sample from Alice. Based on these 2 inputs, classifier 314 generates a confidence value 318, which it provides to a motion authentication classifier 324 of second device 320, which in turn generates a motion factor reference template 326 to be used for authentication purposes. Note that in the embodiment shown motion factor reference template 326 is not the same as high quality motion factor reference template 316 of first device 310 and instead acts as an authentication confidence value, e.g., the error rate described above regard to
Thereafter, an authentication phase 320 may occur. As part of this authentication phase, Alice may generate a new motion sample and provide accelerometer data 331 to motion authentication classifier 324 of second device 320. In an embodiment, an appropriate authentication challenge protocol may occur prior to sending this motion data. During user authentication phase 330, each device may receive a user motion template from the other device. Thus as shown in
As shown in
Thus in various embodiments one or more platform sensors (e.g., at least a motion sensor) may provide input to multiple classifiers for device pairing and user pairing. In some cases security may be enhanced, as these pairing operations may be performed in a TEE. As described above, 2 different devices (each including one or more accelerometers) may be held together during a physical world meeting to obtain simple data that can be used to both derive device IDs and perform simple biometric training during the same physical world meeting.
The pairing and key exchange algorithm may be used to create secure digital relationships where the pairing context (in person meeting with physical possession of devices) is known to both parties. In this way, secure pairing and communication may occur without a trusted third party entity to establish the secure digital relationship context.
Embodiments further leverage use of, e.g., motion sensors, to generate entropy, without the need for creation or access to a gesture database containing a list of gesture motions that are displayed for a user to repeat while pairing. Stated another way, instead of this database-centered approach, here device and user pairing may be performed using the same training data. Also, embodiments may enable devices to perform an exchange of an authentication confidence value that may be used to authenticate users subsequently, so that the user need not share a biometric reference template that may have higher confidence, but may also have stronger privacy constraints.
Key exchange may occur over a trustable session between trusted execution environments using a bilateral attestation protocol, in various embodiments. Furthermore, unlike existing bump-to-pair methods that upload motion information to a cloud service, motion information is shared only with the devices participating in the pairing and if a TEE is used, only within the attested TEE environments. As such, privacy sensitive location data are not shared outside of the devices being paired and if a TEE is used, only within the attested TEE environments.
Referring now to
As seen, one or more motion sensors 505 are provided to receive motion sampling information. Types of motions sensors vary in different examples and can include multi-axis accelerators, positioning sensors, orientation sensors, among others. In turn, motion sampling information from such sources are provided to a security engine 510, which in different implementations may be a standalone security processor (such as a hardware trusted platform module (TPM)) or security logic (such as a separate low complexity core) included within a general-purpose processor such as a multicore processor or other SoC.
As further seen, secure engine 510 further receives motion information from a remote system, namely motion sample information from that system. Based on the multiple motion samples, it can be determined whether the training motion samples for a given user match to at least a threshold level. In an embodiment, a device pairing classifier 514 of secure engine 510 may execute to generate a pairing key based on these local and remote motion samples. In addition, using a reference template for the user of the local device (which may be stored in a secure storage 520), a relationship identity classifier 512 may also execute to generate a confidence value, which may be of a lower quality/lower security level than a local motion reference template. In addition to storing these calculated values in secure storage 520 associated with the local user, the information may further be passed to a pairing logic 530.
In an embodiment, pairing logic 530 may generate a relationship pairing key including private and public keys (which also may be stored in secure storage 520). The corresponding public key of the relationship pairing key and the confidence value may be sent via a communication interface 550, which in an embodiment may provide for both wired and wireless communication (e.g. via a physical connector 552 and an antenna 555, respectively), to the other device.
At this point, assume that the devices are paired and the users desire to open a secure channel at a later time. To this end, authentication procedures may be performed to authenticate the local users to their devices. Furthermore, a motion authentication may be performed and the motion sample from the remote user may be communicated to enable secure engine 510 to determine whether the device and user are authenticated (based on comparison with the previously received remote motion sample obtained during training) Assuming that the devices are paired, pairing logic 530 interfaces with a connection logic 570 which, based on a given connection protocol (e.g., a wireless connection protocol) creates a secure connection between the devices, such as described above to derive a set of keys to be used for encryption of communication between the devices.
In an embodiment, secure engine 510 may generate an authentication result, e.g., to indicate whether a given user is authenticated according to a given authentication process, as dictated by an authentication policy, which also may be stored in secure storage 520. In an embodiment, the authentication policy may provide for a multi-factor authentication, such as by way of a given combination of biometric input, password, motion, or other user-based input.
With further reference to
Referring now to
As seen in the embodiment of
In the embodiment of
As further seen in
Referring now to
In turn, application processor 910 can couple to a user interface/display 920, e.g., a touch screen display. In addition, application processor 910 may couple to a memory system including a non-volatile memory, namely a flash memory 930 and a system memory, namely a DRAM 935. In some embodiments, flash memory 930 may include a secure portion 932 in which secrets, such as device IDs, relationship pairing keys, motion templates, motions samples, and security policies (including pairing and connection policies for the motion-based pairing and authentications as described herein) may be stored. As further seen, application processor 910 also couples to a capture device 945 such as one or more image capture devices that can record video and/or still images.
Still referring to
As further illustrated, a near field communication (NFC) contactless interface 960 is provided that communicates in a NFC near field via an NFC antenna 965. While separate antennae are shown in
A power management integrated circuit (PMIC) 915 couples to application processor 910 to perform platform level power management. To this end, PMIC 915 may issue power management requests to application processor 910 to enter certain low power states as desired. Furthermore, based on platform constraints, PMIC 915 may also control the power level of other components of system 900.
To enable communications to be transmitted and received, various circuitry may be coupled between baseband processor 905 and an antenna 990. Specifically, a radio frequency (RF) transceiver 970 and a wireless local area network (WLAN) transceiver 975 may be present. In general, RF transceiver 970 may be used to receive and transmit wireless data and calls according to a given wireless communication protocol such as 3G or 4G wireless communication protocol such as in accordance with a code division multiple access (CDMA), global system for mobile communication (GSM), long term evolution (LTE) or other protocol. In addition a GPS sensor 980 may be present, with location information being provided to security processor 950 for use as described herein when context information is to be used in a pairing process. Other wireless communications such as receipt or transmission of radio signals, e.g., AM/FM and other signals may also be provided. In addition, via WLAN transceiver 975, local wireless communications, such as according to a Bluetooth™ or IEEE 802.11 standard can also be realized.
The following Examples pertain to further embodiments.
In Example 1, an apparatus comprises: a security logic to receive first motion sample information from at least one motion sensor of a first portable device and second motion sample information from at least one motion sensor of a second portable device, the first and second motion sample information obtained responsive to training movement of the first and second portable devices by a first user, the security logic to generate a device pairing value based on the first motion sample information and the second motion sample information, generate a first confidence value based on the first motion sample information and first reference motion sample information stored in the first portable device corresponding to reference movement of the first portable device by the first user, generate a relationship key pair for a relationship between the first user and a second user of the second portable device, and communicate the first confidence value and a public key of the relationship key pair to the second portable device; and a storage having an entry for the relationship to store the relationship key pair.
In Example 2, the security logic of Example 1 comprises a first classifier to generate the device pairing value and a second classifier to generate the first confidence value.
In Example 3, the apparatus of one of the above Examples includes a connection logic to connect the first portable device to the second portable device via a secure channel and to receive third motion sample information from the second portable device, the third motion sample information obtained responsive to movement of the second portable device by the second user, the connection logic to determine whether the third motion sample information matches fourth motion sample information received from the second portable device and obtained responsive to training movement of the second portable device by the second user to at least a threshold level, and if so to authenticate the second user and the second portable device to the first portable device.
In Example 4, the apparatus of Example 3 further comprises a sharing logic, responsive to the second user and the second portable device authentication, to generate a set of keys derived from the relationship key pair.
In Example 5, the security logic of Example 3 or 4 is optionally to execute in a trusted execution environment of the apparatus to perform the second user and the second portable device authentication without interaction with a trusted third party, the apparatus comprising the first portable device.
In Example 6, the at least one motion sensor of one of the above Examples optionally comprises one or more of a six-axis accelerometer and a nine-axis accelerometer.
In Example 7, a first computing device comprises: at least one first motion sensor to sense motion of the first computing device; a processor to execute instructions and including a security logic to perform a training protocol to receive motion-based training information for a first user and a second user from the at least one first motion sensor and from a second computing device and to generate a first relationship pairing key for a relationship between the first user and the second user based on the motion-based training information without interaction with a trusted third party, where the security logic is to receive the motion-based training information responsive to a training motion operation performed on the first and second computing devices by each of the first and second users, to enable the first computing device to pair with the second computing device; and a first storage to store a first relationship entry including a public key of a second relationship pairing key for the relationship between the first user and the second user received from the second computing device, a private key of the first relationship pairing key, a first motion sample of the motion-based training information for the first user and a second motion sample of the motion-based training information for the second user.
In Example 8, the security logic of Example 7 is to execute in a trusted execution environment of the first computing device.
In Example 9, the security logic of Example 7 or 8 comprises a relationship identify classifier to generate a first confidence value based on a motion reference template for the first user and the first motion sample, and to provide the first confidence value to the second computing device.
In Example 10, the relationship identity classifier of Example 9 is optionally to receive a later motion sample for the second user from the second computing device and to determine whether the later motion sample matches the second motion sample of the motion-based training information for the second user to at least a second confidence value, the second confidence value received from the second computing device.
In Example 11, the security logic of Example 10, responsive to the later motion sample matching the second motion sample to at least the second confidence value, is to enable the first computing device to share information with the second computing device via a secure channel.
In Example 12, the security logic of one of Examples 7-11 comprises a device pairing classifier to generate the first relationship pairing key based on the first motion sample and a third motion sample of the motion-based training information for the first user received from the second computing device.
In Example 13, the device pairing classifier of Example 12 is optionally to perform a logical operation on the first motion sample and the third motion sample to determine whether a result of the logical operation exceeds a threshold, and if so to generate a device pairing value, the device pairing value to be used to communicate a public portion of the first relationship pairing key to the second computing device.
In Example 14, the security logic, responsive to the result of the logical operation of Example 13 not exceeding the threshold, is to prevent the first computing device from pairing with the second computing device.
In Example 15, the security logic of one of Examples 7-14 is further to generate the first relationship pairing key based on context information associated with an in-person interaction between the first user and the second user.
In Example 16, the security logic of Example 15 is optionally to encrypt the shared information using the private key of the first relationship pairing key.
In Example 17, at least one computer readable storage medium comprises instructions that when executed enable a first system to: receive motion sample information from a local motion sensor associated with the first system and from a remote motion sensor associated with a second system, the motion sample information responsive to training movement of the first and second systems by a first user; generate a first pairing key for the first user based on the motion sample information; and generate and store a first relationship key pair including a first public key and a first private key based at least in part on the first pairing key and store the first relationship key pair in a first entry of a storage associated with a relationship between the first user and a second user of the second system, the first relationship key pair to enable the first and second systems to pair when located remotely to each other.
In Example 18, the at least one computer readable storage medium of Example 17 optionally further comprises instructions that when executed enable the first system to: generate a reference motion template for the first user based at least in part on collected motion sample information from the local motion sensor and store the reference motion template in a first storage of the first system.
In Example 19, the at least one computer readable storage medium of Example 18 optionally further comprises instructions that when executed enable the first system to generate a first confidence value based on the reference motion template, the first confidence value of a lower security level than the reference motion template, and send the first confidence value to the second system to enable the second system to authenticate future motion sample information from the first system, the future motion sample information responsive to pairing movement of the first system by the first user.
In Example 20, the at least one computer readable storage medium of Example 18 optionally further comprises instructions that when executed enable the first system to authenticate the second user and the second system without interaction with a trusted third party.
In Example 21, a method comprises: receiving motion sample information from a local motion sensor associated with a first system and from a remote motion sensor associated with a second system, the motion sample information responsive to training movement of the first and second systems by a first user; generating a first pairing key for the first user based on the motion sample information; and generating and storing a first relationship key pair including a first public key and a first private key and storing the first relationship key pair in a first entry of a storage associated with a relationship between the first user and a second user of the second system, the first relationship key pair to enable the first and second systems to pair when located remotely to each other.
In Example 22, the method of Example 21 further comprises generating a reference motion template for the first user based at least in part on collected motion sample information from the local motion sensor and storing the reference motion template in a first storage of the first system.
In Example 23, the method of Example 22 optionally further comprises generating a first confidence value based on the reference motion template, the first confidence value of a lower security level than the reference motion template, and sending the first confidence value to the second system to enable the second system to authenticate future motion sample information from the first system, the future motion sample information responsive to pairing movement of the first system by the first user.
In Example 24, the method of Example 22 optionally further comprises authenticating the second user and the second system without interaction with a trusted third party.
In Example 25, a machine-readable storage medium includes machine-readable instructions, when executed, to implement a method of any one of Examples 21 to 24.
In Example 26, an apparatus comprises means for performing the method of any one of Examples 21 to 24.
In Example 27, an apparatus comprises: means for receiving motion sample information from a local motion sensor associated with a first system and from a remote motion sensor associated with a second system, the motion sample information responsive to training movement of the first and second systems by a first user; means for generating a first pairing key for the first user based on the motion sample information; means for generating and storing a first relationship key pair including a first public key and a first private key based at least in part on the first pairing key; and means for storing the first relationship key pair in a first entry of a storage associated with a relationship between the first user and a second user of the second system, the first relationship key pair to enable the first and second systems to pair when located remotely to each other.
In Example 28, the apparatus of Example 27 further comprises: means for generating a reference motion template for the first user based at least in part on collected motion sample information from the local motion sensor; and means for storing the reference motion template in a first storage of the first system.
In Example 29, the apparatus of Example 28 optionally further comprises means for generating a first confidence value based on the reference motion template, the first confidence value of a lower security level than the reference motion template, and sending the first confidence value to the second system to enable the second system to authenticate future motion sample information from the first system, the future motion sample information responsive to pairing movement of the first system by the first user.
In Example 30, the apparatus of Example 28 optionally further comprises means for authenticating the second user and the second system without interaction with a trusted third party.
Understand also that various combinations of the above Examples are possible.
Embodiments may be used in many different types of systems. For example, in one embodiment a communication device can be arranged to perform the various methods and techniques described herein. Of course, the scope of the present invention is not limited to a communication device, and instead other embodiments can be directed to other types of apparatus for processing instructions, or one or more machine readable media including instructions that in response to being executed on a computing device, cause the device to carry out one or more of the methods and techniques described herein.
Embodiments may be implemented in code and may be stored on a non-transitory storage medium having stored thereon instructions which can be used to program a system to perform the instructions. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, solid state drives (SSDs), compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.
