Mobile device and key fob pairing for multi-factor security

Systems and methods may provide for determining a first proximity status of a first mobile device with respect to a vehicle, and determining a second proximity status of a second mobile device with respect to the vehicle. Additionally, an accessibility of one or more functions of the vehicle may be configured based at least in part on the first proximity status and the second proximity status. In one example, a policy associated with one or more of the first mobile device and the second mobile device may be identified, wherein the accessibility is configured further based on the policy.

BACKGROUND

Embodiments generally relate to security systems. More particularly, embodiments relate to the use of multiple factors to control access to vehicles.

Vehicle entry systems may include proximity-based keyless remotes (e.g., key fobs) that may be used to access and/or start the vehicle. While these solutions may be suitable under certain circumstances, there remains considerable room for improvement. For example, unauthorized access and/or operation of the vehicle may be achieved by simply gaining possession of the key fob, which may be the sole user authentication factor with respect to the vehicle. Moreover, if the key fob is lost or stolen, a new key fob may need to be ordered, which may be of considerable cost, delay and inconvenience to the owner. Although certain smart phone applications may allow remote control of vehicles, these applications may also be limited to the use of login credentials to establish the phone as the only user authentication factor with respect to the vehicle, wherein the login credentials may be easily compromised. Moreover, smart phone-based solutions may involve the use of an intermediary (e.g., service provider) between the phone and the vehicle.

DETAILED DESCRIPTION

Turning now toFIG. 1, an authentication environment10is shown in which access to and control over a vehicle14is managed relative to a plurality of mobile devices16,18that are paired with the vehicle14. In the illustrated example, a first mobile device16is a key fob (e.g., wireless hardware security token) and a second mobile device18is a smart phone. The mobile devices16,18may also include other types of devices such as smart tablets, personal digital assistants (PDAs), media players, imaging devices, and so forth, wherein a user12may carry the mobile devices16,18with him or her as the user approaches and interacts with the vehicle14. As will be discussed in greater detail, the presence of the mobile devices16,18may be required in order to authenticate the user12, wherein successful authentication may result in certain functions of the vehicle14being made available to the user12. For example, the presence of both mobile devices16,18may be required before the user12is permitted to access the vehicle14(e.g., door and/or trunk unlock function), start the vehicle14(e.g., ignition function), customize various settings (e.g., user setting function), drive the vehicle14(e.g., vehicle operation function), pair devices with the vehicle14(e.g., device pairing function), and so forth. Accordingly, the illustrated environment10represents a “multi-factor” authentication environment in which the security of the vehicle14is a function of the proximity status of multiple mobile devices16,18.

As will also be discussed in greater detail, user policies and/or profiles may also be used to make certain functions, such as vehicle access and device pairing, available to the user12even if only one of the mobile devices16,18is present. Additionally, although two mobile devices are shown, more than two mobile devices may also be used by a given user to access vehicle functions. For example, the user12may pair a smart phone, smart tablet and media player with the vehicle14, and designate the smart phone as the primary (e.g., “master”) device, wherein the primary device may be used to pair other devices with the vehicle14.

For example,FIG. 2Ademonstrates that a policy may be implemented in which the user12is permitted to enter the vehicle14if the first mobile device16is present but the second mobile device18is not present. Such a case might occur if the second mobile device18becomes lost or stolen, or the user12merely forgets to bring the second mobile device18. The policy, which may be implemented as a user profile corresponding to the user12or as a global policy (e.g., default profile) applicable to all users or groups of users, may also permit a replacement device20(e.g., smart phone) to be paired with the vehicle14, provided that the user12successfully satisfies a login constraint (e.g., inputs a predefined passcode) associated with the user profile of the user12and completes a pairing process.

Similarly,FIG. 2Bdemonstrates that the user profile may permit the user12to enter the vehicle14if the second mobile device18is present but the first mobile device16is not present. Such a case might occur if the first mobile device16becomes lost or stolen, or the user12merely forgets to bring the first mobile device16. The user profile may also permit a replacement device22(e.g., key fob) to be paired with the vehicle14, provided that the user12successfully satisfies the login constraint associated with the user profile of the user12and completes the pairing process. Accordingly, the use of a multi-factor authentication scheme may enable new factors to be paired with the vehicle14at considerably less cost, delay and inconvenience to the user12, while maintaining a relatively high level of security with respect to the vehicle14.

Turning now toFIG. 3, a logic architecture24(24a-24d) is shown, wherein the logic architecture24may be generally incorporated into a vehicle such as, for example, the vehicle14(FIGS. 1,2A and2B) as hardware, software, firmware, or any combination thereof. In the illustrated example, a first factor module24auses a proximity sensor (not shown) to determine a first proximity status of the first mobile device16with respect to the vehicle. Similarly, a second factor module24bmay user a proximity sensor to determine a second proximity status of the second mobile device18with respect to the vehicle. A security module24cmay have a request component40that receives a user request via a user interface (UI)30(e.g., pushbutton, switch, etc.) of the first mobile device16, a UI32(e.g., touch screen, microphone, etc.) of the second mobile device32, a UI34(e.g., door handle, pushbutton, touch screen, etc.) of the vehicle, etc., and configure an accessibility of one or more functions26(26a-26c) of the vehicle in response to the user request based at least in part on the first proximity status and the second proximity status. In one example, the security module24cidentifies a policy such as one or more user profiles28, wherein at least one of the user profiles28may be associated with the first mobile device16and/or the second mobile device18(and a user corresponding to such device(s)). In such a case, the vehicle functions26may be configured further based on the identified user profile.

For example, the security module24cmight have a denial component36that denies user requests if the first proximity status and the second proximity status do not satisfy a multi-factor condition of the user profile. More particularly, the multi-factor condition may stipulate that both mobile devices16,18(e.g., factors) be present in order for the vehicle function in question to be available to the user. In such a case, if the first proximity status indicates that the first mobile device16is present but the second proximity status indicates that the second mobile device18is not present, the multi-factor condition would not be satisfied. Similarly, if the second proximity status indicates that the second mobile device18is present but the first proximity status indicates that the first mobile device16is not present, the multi-factor condition would also not be satisfied.

Other conditions, such as time-based or location-based conditions may also be used. For example, if the user profile stipulates that the user in question (or all users if a global policy and/or default profile is implemented) is to operate the vehicle within a certain radius of a particular location (e.g., street address) and it is determined that the vehicle is outside that radius, the denial component36may deny operation of the vehicle (e.g., prevent ignition of the vehicle, shutdown the vehicle after providing a warning to the driver, etc.). By way of another example, if the user profile stipulates that the user in question is to operate the vehicle within a certain time period and it is determined that the current time is outside the specified time period, the denial component36may also deny operation of the vehicle. In addition, enforcement of the multi-factor conditions may be conducted on an ongoing basis. For example, if it is determined that, after a given user request has been granted, a condition leading to the grant of the request is no longer satisfied, the grant of the condition may be effectively reversed. Thus, shutdown of the vehicle may be implemented in such a scenario as well. Other examples may include the prohibition of radio usage while the vehicle is being operated to prevent distracted driver scenarios.

The security module24cmay also have a grant component38that grants user requests if the first proximity status and the second proximity status satisfy the multi-factor condition of the user profile. As will be discussed in greater detail, the grant component38may also apply one or more constraints such as, for example, a time constraint, location constraint, login constraint, etc., of the user profile to the vehicle function in question. With specific regard to the login constraint, the illustrated architecture24also includes a pairing module24dconfigured to pair the first and second mobile devices16,18, as well as replacement devices such as device20(FIG. 2A) and device22(FIG. 2B), with the vehicle. The mobile devices16,18, and replacement devices20(FIG. 2A),22(FIG. 2B) may also be paired with one another. If both factors are present, the pairing module24dmay manage the pairing process normally. If, on the other hand, only one of the factors is present, the pairing module24dmay permit entry to the vehicle and then prompt the user to enter a passcode (e.g., personal identification number/PIN, password, etc.) before proceeding with the pairing process.

With further regard to the pairing module24d, the passcode may be entered on one of the mobile devices16,18, or in some embodiments may be required to be entered directly into the vehicle UI34in order to pair the devices16,18. In another embodiment, automatic pairing may be enabled, wherein a default policy and/or user profile may be used until a “master” (e.g., primary) device is defined. For example, one device may be considered to be a master that is to be present in order to pair other devices together and with the vehicle (one master key fob, for instance). In some embodiments, pairing may only be completed when the master device is also present (e.g., in order to pair a lesser privileged smart phone, for instance, operated by a child, minor, or other non-owner of the vehicle and a smart phone). In some embodiments, a second device (e.g., smart phone rather than key fob) may be identified as a master device at the time of pairing to enable entry of user constraints on other secondary devices. These other secondary “non-master” devices (e.g., lesser privileged smart phone) may be prevented from changing their own user constraints. Secondary devices may receive user constraints to be stored on the device via a number of means: Bluetooth, wireless, NFC (near field communication), synching to computer or other docking station, etc. The user constraints may then be non-modifiable, however except in the presence of the master device.

Additionally, the illustrated security module24chas a notification component42configured to generate a notification via the UI30of the first mobile device16, the UI32of the second mobile device18, and/or the UI34of the vehicle if either the first proximity status indicates that the first mobile device is not present or the second proximity status indicates that the second mobile device is not present. More particularly, such a notification may be useful in cases where a bona fide user is attempting to operate the vehicle without one of the factors (e.g., forgotten factor is missing) as well as cases where an unauthorized user is attempting to operate the vehicle without one of the factors (e.g., stolen factor is present). The notification may be sent to the nearby factor (e.g., in the case of a forgotten factor) and/or the missing factor (e.g., in the case of a stolen factor), depending upon the circumstances.

In the illustrated example, each of the mobile devices16,18, includes a policy repository17to store a policy that has one or more multi-factor conditions, as well as a wireless interface19to receive a request from the security module24cof the vehicle and transmit the policy to the security module24cin response to the request. In one example, the policy is a user profile. As already noted, a given multi-factor condition may indicate whether the functions26of the vehicle are to be accessible if either the first mobile device16or the second mobile device18are not in proximity of the vehicle during an attempted access of the functions26of the vehicle. The policy may be transmitted to the security module24cin conjunction with a pairing process and/or an attempt to access one or more of the functions26of the vehicle.

With further regard to the pairing process, the illustrated mobile devices16,18also include a pairing module21that is configured to pair the respective device with the vehicle and/or other devices. In one example, the pairing module21of the first mobile device16receives a passcode via the UI30and determines whether the passcode satisfies a login constraint of the policy, wherein the first mobile device16is paired if the passcode satisfies the login constraint. Similarly, the pairing module21of the second mobile device18may receive a passcode via the UI32and determine whether the passcode satisfies the login constraint of the policy, wherein the second mobile device18is paired if the passcode satisfies the login constraint. Alternatively, the determination as to whether the passcode satisfies the login constraint may be conducted by the vehicle. Moreover, in some instances, a mobile device such as, for example, the first mobile device16(e.g., key fob) may not have the capability to support the entry of login credentials. In such a case, the UI34of the vehicle may be used, or the login process may be bypassed altogether if the device is a master device.

FIG. 4shows a set of user profiles28structured as a table. In the illustrated example, a plurality of users (e.g., “Dad”, “Mom”, “Sally”) each has various preferences that are programmable/configurable. For example, a passcode, the number of factors required to access the vehicle (“Access Factors”), the number of factors required to activate the vehicle ignition (“Start Factors”), the number of factors required to operate the vehicle (“Drive Factors”), location constraints, time constraints, and so forth, may all be defined on a user-by-user basis. Moreover, the specified parameters may be used to determine whether to grant user requests, as well as to apply user-specific conditions to granted requests. Of particular note is that different users may have different policies. For example, Mom and Dad are able to start the vehicle with only one factor present, whereas Sally's profile calls for two factors to be present in order to start the vehicle, in the illustrated example. Although the illustrated set of user profiles28is structured as a table, the set of user profiles28may also utilize other known structures such as relational database structures and/or linked lists to track, manage, control and organize the data represented therein.

Turning now toFIG. 5, a method44of managing a multi-factor authentication environment is shown. The method44may be implemented as a set of logic instructions and/or firmware stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), flash memory, etc., in configurable logic such as, for example, programmable logic arrays (PLAs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), in fixed-functionality logic hardware using circuit technology such as, for example, application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof. For example, computer program code to carry out operations shown in the method44may be written in any combination of one or more programming languages, including an object oriented programming language such as C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. Moreover, the method44may be implemented as the logic architecture24(FIG. 3) using any of the aforementioned circuit technologies.

Illustrated processing block46provides for receiving a user request via a user interface of, for example, a first mobile device, a second mobile device, a vehicle, and so forth. The user request may correspond to one or more functions of the vehicle such as a door unlock function (e.g., access request), an ignition function (e.g., start request), a user setting function (e.g., seat preferences, radio preferences), a vehicle operation function (e.g., placing/maintaining the transmission in drive), a pairing function (e.g., replacement device), and so forth. A determination may be made at block48as to whether a multi-factor condition is satisfied. As already noted, the multi-factor condition may take into consideration a first proximity status of a first mobile device with respect to the vehicle, a second proximity status of a second mobile device with respect to the vehicle, etc., wherein the multi-factor condition may specify whether both mobile devices are to be present in order to make the vehicle function in question available to the user. If the multi-factor condition is not satisfied, block52may deny the user request. Block52may also provide for generating a notification via user interface of, for example, the first mobile device, the second mobile device, the vehicle, or any combination thereof, in order to inform the vehicle owner of a missing, lost and/or stolen mobile device, as already discussed.

If, on the other hand, the multi-factor condition is satisfied, illustrated block50grants the user request and applies any relevant constraints to the request. Both the multi-factor condition and the constraints may be defined on a user-by-user basis and stored in an appropriate profile, policy, etc. In one example, the constraint is a location constraint in which the vehicle function is only available in certain locations. In another example, the constraint is a time constraint in which the vehicle function is only available at certain times and/or for certain durations of time. In yet another example, the constraint is a login constraint in which the vehicle function is only available if the user inputs a predetermined passcode. The login constraint may be particularly useful for pairing devices and replacement devices.

FIG. 6also illustrates a memory270coupled to the processor200. The memory270may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. The memory270may include one or more code213instruction(s) to be executed by the processor200core, wherein the code213may implement the logic architecture24(FIG. 3), already discussed. The processor core200follows a program sequence of instructions indicated by the code213. Thus, the processor core200may be part of a vehicle such as the vehicle14(FIG. 1). The processor core200may also be used in a mobile device such as the mobile devices16,18(FIG. 3) to support the functionality of those devices. Each instruction may enter a front end portion210and be processed by one or more decoders220. The decoder220may generate as its output a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals which reflect the original code instruction. The illustrated front end210also includes register renaming logic225and scheduling logic230, which generally allocate resources and queue the operation corresponding to the convert instruction for execution.

Although not illustrated inFIG. 6, a processing element may include other elements on chip with the processor core200. For example, a processing element may include memory control logic along with the processor core200. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches.

Referring now toFIG. 7, shown is a block diagram of a system1000in accordance with an embodiment of the present invention. In one example, the system1000is part of a vehicle such as the vehicle14, already discussed. The system1000may also be used in a mobile device such as the mobile devices16,18(FIG. 3) to support the functionality of those devices. Shown inFIG. 7is a multiprocessor system1000that includes a first processing element1070and a second processing element1080. While two processing elements1070and1080are shown, it is to be understood that an embodiment of system1000may also include only one such processing element.

Each processing element1070,1080may include at least one shared cache1896. The shared cache1896a,1896bmay store data (e.g., instructions) that are utilized by one or more components of the processor, such as the cores1074a,1074band1084a,1084b, respectively. For example, the shared cache may locally cache data stored in a memory1032,1034(e.g., computer readable medium, computer readable storage medium, etc.) for faster access by components of the processor. In one or more embodiments, the shared cache may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.

The first processing element1070and the second processing element1080may be coupled to an I/O subsystem1090via P-P interconnects1076,1086and1084, respectively. As shown inFIG. 7, the I/O subsystem1090includes P-P interfaces1094and1098. Furthermore, I/O subsystem1090includes an interface1092to couple I/O subsystem1090with a high performance graphics engine1038. In one embodiment, bus1049may be used to couple graphics engine1038to I/O subsystem1090. Alternately, a point-to-point interconnect1039may couple these components.

As shown inFIG. 7, various I/O devices1014may be coupled to the first bus1016, along with a bus bridge1018which may couple the first bus1016to a second bus1020. The I/O devices1014may include, for example, one or more proximity sensors that may be used to determine the proximity status of mobile devices with respect to a vehicle. For example, the proximity sensors may incorporate near field communications (NFC) technology, radio frequency identifier (RFID) technology, infrared (IR) technology, and so forth. In one embodiment, the second bus1020may be a low pin count (LPC) bus. Various devices may be coupled to the second bus1020including, for example, a keyboard/mouse1012, communication device(s)1026(which may in turn be in communication with a computer network, not shown), and a data storage unit1018such as a disk drive or other mass storage device which may include code1030, in one embodiment. The code1030may include instructions for performing embodiments of one or more of the methods described above. Thus, the illustrated code1030may implement the logic architecture24(FIG. 3) and may be similar to the code213(FIG. 6), already discussed. Further, an audio I/O1024may be coupled to second bus1020.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture ofFIG. 7, a system may implement a multi-drop bus or another such communication topology. Also, the elements ofFIG. 7may alternatively be partitioned using more or fewer integrated chips than shown inFIG. 7.

Technologies described herein may therefore reduce cost by enabling general purpose devices such as smart phones, smart tables, etc., to be used for authentication purposes in a vehicle context. In addition, delays associated with replacing lost or stolen authentication devices may be significantly reduced due to the ability to pair a wide variety of devices with the vehicle on-the-fly. Moreover, the use of customizable profiles and/or policies to apply security constraints may be much more convenient to users and may substantially enhance the user experience. In addition, the mobile devices may be configured to communicate directly with the vehicle so that proximity status information can be determined between a general purpose mobile device and the vehicle without involving an intermediary such as a server and/or service provider.

Examples may include an apparatus having a first factor module to determine a first proximity status of a first mobile device with respect to a vehicle and a second factor module to determine a second proximity status of a second mobile device with respect to the vehicle. The apparatus may also include a security module to configure an accessibility of one or more functions of the vehicle based at least in part on the first proximity status and the second proximity status.

Additionally, the security module may identify a policy associated with one or more of the first mobile device and the second mobile device, wherein the accessibility is to be configured further based on the policy.

Additionally, the security module may receive a user request via a user interface of one or more of the first mobile device, the second mobile device and the vehicle, wherein the accessibility is to be configured in response to the user request.

Moreover, the security module may include a denial component to deny the user request if the first proximity status and the second proximity status do not satisfy a multi-factor condition of the policy.

In addition, the security module may include a grant component to grant the user request if the first proximity status and the second proximity status satisfy a multi-factor condition of the policy.

In addition, the grant component may apply one or more of a time constraint of the policy, a location constraint of the policy, and a login constraint of the policy to at least one of the one or more functions of the vehicle.

Moreover, the security module may include a notification component to generate a notification via a user interface of one or more of the first mobile device, the second mobile device and the vehicle if either the first proximity status indicates that the first mobile device is not present or the second proximity status indicates that the second mobile device is not present.

Additionally, at least one of the one or more functions of the vehicle may include one or more of a door unlock function, a trunk unlock function, an ignition function, a user setting function, a vehicle operation function, and a replacement device pairing function.

Additionally, any of the aforementioned apparatus examples may further include a proximity sensor, wherein the first factor module is to use the proximity sensor to determine the first proximity status and the second factor module is to use the proximity sensor to determine the second proximity status.

Examples may also include a method in which a first proximity status of a first mobile device is determined with respect to a vehicle. The method may also provide for determining a second proximity status of a second mobile device with respect to the vehicle, and configuring an accessibility of one or more functions of the vehicle based at least in part on the first proximity status and the second proximity status.

Additionally, the method may further include identifying a policy associated with one or more of the first mobile device and the second mobile device, wherein the accessibility is configured further based on the policy.

Additionally, the method may further include receiving a user request via a user interface of one or more of the first mobile device, the second mobile device and the vehicle, wherein the accessibility is configured in response to the user request.

Moreover, configuring the accessibility may include denying the user request if the first proximity status and the second proximity status do not satisfy a multi-factor condition of the policy.

In addition, configuring the accessibility may include granting the user request if the first proximity status and the second proximity status satisfy a multi-factor condition of the policy.

In addition, configuring the accessibility may further include applying one or more of a time constraint of the policy, a location constraint of the policy, and a login constraint of the policy to at least one of the one or more functions of the vehicle.

Moreover, configuring the accessibility may include generating a notification via a user interface of one or more of the first mobile device, the second mobile device and the vehicle if either the first proximity status indicates that the first mobile device is not present or the second proximity status indicates that the second mobile device is not present.

Additionally, in any of the aforementioned method examples, at least one of the one or more functions of the vehicle may include one or more of a door unlock function, a trunk unlock function, an ignition function, a user setting function, a vehicle operation function, and a replacement device pairing function.

Examples may also include at least one machine readable storage medium having a set of instructions which, when executed by a processor, cause a vehicle to perform any of the aforementioned method examples.

Moreover, examples may include a system having a proximity sensor and a first factor module to use the proximity sensor to determine a first proximity status of a first mobile device with respect to a vehicle. The system may also have a second factor module to use the proximity sensor to determine a second proximity status of a second mobile device with respect to the vehicle, and a security module to configure an accessibility of one or more functions of the vehicle based at least in part on the first proximity status and the second proximity status.

Examples may also include a mobile device having a policy repository to store a policy with a multi-factor condition. The mobile device may also include a wireless interface to receive a request from a security module of a vehicle and transmit the policy to the security module in response to the request.

Additionally, the multi-factor condition may indicate whether one or more functions are to be accessible if either the first mobile device or a second mobile device are not in proximity of the vehicle.

Additionally, the mobile device may further include a pairing module to pair the first mobile device with the vehicle.

Moreover, the pairing module may receive a passcode via a user interface of the first mobile device, wherein the first mobile device is to be paired with the vehicle only if the passcode satisfies a login constraint of the policy.

In addition, the wireless interface may receive a notification that the first mobile device is a master device, wherein the policy is to include a plurality of user profiles.

In addition, the wireless interface of any of the aforementioned mobile device examples may receive a notification that either the first mobile device or the second mobile device is not within proximity of the vehicle during an attempted access of one or more functions of the vehicle.

Examples may also include at least one machine readable storage medium comprising a set of instructions which, when executed by a processor, cause a first mobile device to perform methods of any of the aforementioned mobile device examples.