US20210076208A1 - Out-of-band key sharing using near-field communication - Google Patents

Abstract

A vehicle includes a keypad mounted to an exterior of the vehicle, the keypad having a plurality of buttons, each button representing both a first value and a second value. The vehicle further includes a body controller, programmed to receive an input sequence entered via the keypad, validate whether the input sequence matches a predefined keycode, assuming the input sequence correctly entered the first value or the second value according to indications of which values of the keycode are the first value and which are the second value, and confirm pairing a mobile device to the vehicle responsive to the input sequence matching the keycode.

Description

TECHNICAL FIELD
• Aspects of the disclosure generally relate to out-of-band key sharing using near-field communication (NFC) through the use of vehicle keypads.
BACKGROUND
• Vehicle key fobs may be used to allow a user to gain access to a vehicle. Some fob devices operate such that when a key is pressed on the fob, the device sends a code to the vehicle to instruct the vehicle to unlock the vehicle. Passive-entry key fobs operate to provide response to a challenge pulse train sent by the vehicle, where if a proper response is received by the vehicle then the door may be unlocked by a user grasping the door handle.
• Phone-as-a-key (PaaK) systems are being introduced to allow users to utilize their phones to unlock a vehicle without requiring a key fob device. These systems may operate similar to a key fob, but where the phone communicates with the vehicle over Bluetooth Low Energy or other mobile device wireless technologies. The communication may require a bonded state, whereby an exchange of encryption keys between the phone and vehicle is performed. When performing the bonding, the user may be asked to input a confirmation code to verify the device identifiers.
• Near-field communication (NFC) technology is a mechanism by which electronic devices establish communication by being brought within a short distance of one another (on the order of 4 centimeters). NFC tags or cards are data stores which can be read by NFC reader devices. NFC cards may be used for a variety of applications, including contactless payments and access control. In some cases, NFC functionality may be implemented by smartphones or other mobile devices.
SUMMARY
• In one or more illustrative examples, a vehicle includes a keypad mounted to an exterior of the vehicle, the keypad having a plurality of buttons, each button representing both a first value and a second value; and a body controller, programmed to receive an input sequence entered via the keypad, validate whether the input sequence matches a predefined keycode, assuming the input sequence correctly entered the first value or the second value according to indications of which values of the keycode are the first value and which are the second value, and confirm pairing a mobile device to the vehicle responsive to the input sequence matching the keycode.
• In one or more illustrative examples, a method includes receiving a keycode, including a sequence of values to pair a mobile device to a vehicle; indicating which of the sequence of values are even and which are odd; receiving an input sequence entered via a keypad of the vehicle, the keypad having a plurality of buttons, each button representing both an even value and an odd value such that it cannot be determined whether an even value or an odd value was entered; validating, by a controller, whether the input sequence matches the keycode, assuming the input sequence entered even or odd values correctly according to predefined indications provided to the controller of which values of the keycode are even and which are odd; and confirming access responsive to the input sequence matching the keycode.
• In one or more illustrative examples, a system includes a keypad mounted to an exterior of a vehicle, the keypad having a plurality of buttons, each button representing both an even value and an odd value; a body controller; and a short-range wireless controller, programmed to identify an initial wireless connection from a mobile device to the vehicle, identify to use the keypad for keycode pairing of the mobile device to the vehicle responsive to receipt, to the keypad, of receipt of a predefined input, generate a keycode including a sequence of values, send the keycode to the mobile device for display, and indicate to the body controller which of the sequence of values of the keycode are even and which are odd, wherein the body controller is programmed to receive an input sequence entered via the keypad, validate whether the input sequence matches a predefined keycode, assuming the input sequence always entered even or odd values according to indications of which values of the keycode are even and which are odd, and confirm access responsive to the input sequence matching the keycode.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates an example keyless entry system for a vehicle implementing out-of-band key sharing using NFC;
• FIG. 2 illustrates an example scenario in which a first mobile device is sharing access to a vehicle with a second mobile device;
• FIG. 3 illustrates an example process for the direct out-of-band pairing of a mobile device to the Bluetooth low energy module to facilitate vehicle access;
• FIG. 4 illustrates an example process for the entry of a keycode into the keypad of the vehicle to allow access to the vehicle; and
• FIG. 5 illustrates an example process for the management of a revocable key share access key.
DETAILED DESCRIPTION
• As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
• Vehicle sharing is a useful feature of PaaK systems. Vehicle sharing allows a user to share a digital key from the user's device to a trusted user's phone or other mobile device. Once shared, the key may allow the trusted user to gain access to the vehicle and/or use the vehicle for transportation. However, the vehicle should not be required to have cellular connectivity. For instance, if a cellular subscription for the vehicle terminates, the user should still be able to share their vehicle.
• In some systems the user may be required to input a Bluetooth low energy (BLE) confirmation code on the inside of the vehicle to confirm the device bonding process. This would be undesirable for vehicle sharing, as the new user would be required to enter the vehicle and input the code to gain PaaK capabilities. Instead of requiring the recipient user to enter a code inside the vehicle, an alternative process for out-of-band pairing may be utilized. In the scenario where the mobile device of the sharing user receives a key share acknowledgement from a cloud server, the mobile device may receive a secure payload from the server that includes the digital key. In some use cases, this will be a consumer access key (CAK), which is a digital key that allows direct out-of-band pairing to the wireless module. Alternatively, this payload may include the CAK and also a unique access key to grant unlock status. That access key may be unique for key sharing purposes. NFC may then be utilized to obtain vehicle access with the transmission of a secure activation request, as relayed by the key share requester's mobile device, such that temporary access may be granted via an external vehicle keypad. This approach provides vehicle security and also does not require vehicle cellular connectivity for the pairing stage.
• FIG. 1 illustrates an examplekeyless entry system100 for avehicle102 implementing out-of-band key sharing using near-field communication (NFC). Thesystem100 may include abody controller108 in communication with a BLE module (BLEM)112 having a plurality ofBLE transceivers110, withNFC sensors114, and also with akeypad118. In some cases, theNFC sensors114 may be integrated into thekeypad118. These devices may be used to receive authentication information from amobile device104 to facilitate access to thevehicle102.
• Thevehicle102 may include various types of automobile, crossover utility vehicle (CUV), sport utility vehicle (SUV), truck, recreational vehicle (RV), boat, plane or other mobile machine for transporting people or goods. In many cases, thevehicle102 may be powered by an internal combustion engine. As another possibility, thevehicle102 may be a battery-electric vehicle (BEV) powered by one or more electric motors, a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electrical vehicle (PHEV), or a parallel/series hybrid electric vehicle (PSHEV). As the type and configuration ofvehicle102 may vary, the capabilities of thevehicle102 may correspondingly vary. As some other possibilities,vehicles102 may have different capabilities with respect to passenger capacity, towing ability and capacity, and storage volume. For title, inventory, and other purposes,vehicles102 may be associated with unique identifiers, such as VINs.
• Themobile device104 may be any of various types of portable computing device, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other devices having processing and communications capabilities. Themobile device104 may include one or more processors configured to execute computer instructions, and a storage medium on which the computer-executable instructions and/or data may be maintained. Themobile device104 may further include various wireless transceivers, such as a BLUETOOTH or BLE transceiver, and/or NFC106 functionality.
• Thecontroller108 may be one of a plurality of controllers of thevehicle102 configured to perform and managevarious vehicle102 functions under the power of the vehicle battery and/or drivetrain. The controllers may include hardware having processing and communications capabilities. As depicted, thecontroller108 is represented as a discrete hardware component. However, vehicle controllers such as thecontroller108 may share physical hardware, firmware, and/or software, such that the functionality of multiple controllers may be integrated into a single controller, and that the functionality of various such controllers may be distributed across a plurality of controllers.
• The BLEtransceivers110 may be configured to facilitate communication between themobile device104 and thevehicle102. For instance, each BLEtransceiver110 may be connected to one or more antennas to form an array that may be used to triangulate or otherwise detect the location of themobile device104. The BLEtransceivers110 may be controlled by the BLEM112, which includes a memory and a processor programmed to send and receive messaging between themobile device104 and thevehicle102, e.g., to provide for the performance of challenge-response sequences and/or to receive/transmit commands from/to themobile device104/vehicle102. In an example, themobile device104 may connect to the closest-detectedBLE transceiver110 to communicate with the BLEM112 of thevehicle102.
• TheNFC sensors114 may include one or more sensors on the exterior of the vehicle which may be used in conjunction with themobile device104 to unlock or lock thevehicle102 using NFC. Additionally or alternately, theNFC sensors114 may further includeNFC sensors114 within the vehicle which may be used in conjunction with themobile device104 to start thevehicle102.
• A lock/unlock mechanism116 may be operably coupled to thecontroller108. Thecontroller108 may be configured to control the lock/unlock mechanism116 to lock/unlock doors of thevehicle102 in response to the wireless commands transmitted to thebody controller108 by themobile device104 via BLE. Additionally, thecontroller108 may control the lock/unlock mechanism116 to unlock the doors responsive to receipt of a signal from theexterior NFC sensors114 indicative of information received via theNFC106 functionality of themobile device104.
• Thekeypad118 may be in electrical communication with thecontroller108. Thekeypad118 may be positioned on an exterior portion or section of thevehicle102. In one example, thekeypad118 may be hardwired to thecontroller108. In another example, thekeypad118 may be in RF communication with thecontroller108. Thekeypad118 includes a plurality of mechanical pads, capacitive pads orother buttons120a-120nwhich, for example, correspond to numeric characters, alpha characters or any combination of alpha-numeric characters. Thus, to enter a digit of an access code, such as a personal code or factory code or other personal identification number, the user may simply touch or push thecorresponding button120.
• In an example, thekeypad118 may transmit commands via hardwired signals to thecontroller108 which correspond to a sequence of numeric characters, alpha characters, or alpha-numeric characters in response to the user selectingvarious buttons120a-120n. In another example, thekeypad118 may transmit commands via RF signals which correspond to the alpha, numeric, or alpha-numeric characters to thecontroller108 in response to the user selectingvarious buttons120a-120n. In some cases, each of the buttons may represent multiple characters, symbols, or numbers. For instance, in some implementations each button represents two consecutive numbers, one even, one odd. Thecontroller108 may control the lock/unlock mechanism116 to lock/unlock the doors in response to receiving the commands, e.g., two or more signals (RF or hardwired) which correspond to a valid sequence of alpha, numeric, or alpha-numeric characters.
• Thecontroller108 may include an ignitionswitch authentication device122. The ignitionswitch authentication device122 may also include an RF receiver (not shown) and an antenna (not shown) for receiving RF signals transmitted by the RF transmitters of the keys. It should be noted that in some examples, the ignitionswitch authentication device122 may be implemented as a standalone controller (or module). The ignitionswitch authentication device122 is configured to authenticate the particular type of mechanism used to start thevehicle102. For example, with the PATS implementation, the key is inserted into anignition switch124 to start thevehicle102. In such a case, the RF transmitter of the key transmits RF signals having encrypted data therein to the receiver of the ignitionswitch authentication device122. The ignitionswitch authentication device122 decrypts the data to authenticate the key prior to allowing the user to start thevehicle102.
• Thevehicle102 may also include a telematics control unit (TCU)126. TheTCU126 may include network hardware configured to facilitate communication between the vehicle and other devices of thesystem100. For example, theTCU126 may include or otherwise access a cellular modem configured to facilitate communication with a wide-area network128. The wide-area network128 may include one or more interconnected communication networks such as the Internet, a cable television distribution network, a satellite link network, a local area network, and a telephone network, as some non-limiting examples. Thecloud server130 may be an example of a networked computing device that is accessible to thevehicle102 and/or themobile device104 over the wide-area network128.
• Themobile device104 may include anaccess application132 installed to a memory of themobile device104. Theaccess application132 may allow the user to utilize themobile device104 as an access device to provide entry to thevehicle102. In addition, theaccess application132 may be able to receive information from thecloud server130, e.g., transmitted from thecloud server130 over the wide-area network128.
• FIG. 2 illustrates anexample scenario200 in which a first mobile device104-A is sharing access to avehicle102 with a second mobile device104-B. In thisscenario200, the mobile device104-A has utilized theaccess application132 to send ashare request202 over the wide-area network128 to thecloud server130. Theshare request202 indicates assent by the user of the mobile device104-A to allow the user of the mobile device104-B access to thevehicle102. Thecloud server130 receives thisshare request202 over the wide-area network128. In response, thecloud server130 sends, over the wide-area network128, sharecredentials204 to the mobile device104-B and to thevehicle102. These sharecredentials204 may be used by thevehicle102 to validate access of the mobile device104-B to thevehicle102.
• Theshare credentials204 may include, in an example, a secure payload from thecloud server130 that includes a digital access key (e.g., the CAK). In some use cases, this will be only the CAK, which allows direct out-of-band pairing to theBLEM112.
• FIG. 3 illustrates anexample process300 for the direct out-of-band pairing of amobile device104 to theBLEM112 to facilitatevehicle102 access. In an example, theprocess300 may be performed by a mobile device104 (e.g., the mobile device104-B in the scenario200), in the context of thesystem100. As shown, theprocess300 begins atoperation302 responsive to the identification by themobile device104 of an initial connection to thevehicle102. This initial connection may be, for instance, via BLE.
• Atoperation304, themobile device104 notifies the user to place themobile device104 against thevehicle102. This may be done to allow themobile device104 to transmit credentials from themobile device104 to thevehicle102. The notification to the user may be performed in various ways and in various combinations. In one example, themobile device104 may provide a visual notification to a screen of themobile device104. In another example, themobile device104 may provide an audible notification, such as a predefined chime or a voice message requesting the user to place themobile device104 within proximity to thevehicle102. The voice message or visual notification may indicate to the user the location of where themobile device104 should be placed, e.g., against anNFC sensor114 of the vehicle integrated with thekeypad118. In yet another example, themobile device104 may provide haptic feedback using a haptic feedback device of themobile device104. Responsive to the notification, the user may place themobile device104 to thevehicle102 such that NFC communication between theNFC functionality106 of themobile device104 and theNFC sensors114 of the vehicle is provided for.
• Themobile device104 provides credentials to thevehicle102 atoperation306. In an example, this transfer may be performed via the NFC communication between theNFC functionality106 of themobile device104 and theNFC sensors114 of the vehicle. The credentials that are transferred may include, for instance, the CAK received by themobile device104 and thevehicle102. Responsive to receipt of the credentials, theNFC sensors114 may provide the received information to thecontroller108, which may validate that the CAK matches that which was received from thecloud server130.
• Atoperation308, themobile device104 may determine whether the credentials were validated. In an example, themobile device104 may receive confirmation over NFC from thevehicle102 that the credentials were or were not validated as authorized. In another example, themobile device104 may not receive any response from thevehicle102, which may be interpreted after a predetermined timeout period to be a lack of authorization. If themobile device104 is authorized, control passes tooperation310. Otherwise, theprocess300 ends.
• At310, themobile device104 presents confirmation that themobile device104 may be utilized as a PaaK. In an example, themobile device104 may execute one or more of to: display a notification indicating so to a display of themobile device104, make a sound indicative of successful authorization, and/or vibrate in a manner indicative of successful authorization. Afteroperation310, theprocess300 ends.
• Referring back toFIG. 2, the secure payload may additionally or alternately include a unique access key to thecontroller108 that may be used to grant access to thevehicle102. That access key may be unique to a specific user and may be of a length suitable for typing into thekeypad118 of thevehicle102. TheNFC functionality106 of themobile device104 and theNFC sensors114 of thevehicle102 may then be utilized to provide vehicle access with the transmission of a secure activation request from the mobile device104-B to thevehicle102, such that temporary access may be granted to thevehicle102 via thekeypad118. This approach provides vehicle security and, also, does not require vehicle cellular connectivity at any stage.
• FIG. 4 illustrates anexample process400 for the entry of a keycode into thekeypad118 of thevehicle102 to allow access to thevehicle102. In an example, theprocess400 may be performed by thevehicle102 in thescenario200, in the context of thesystem100. Atoperation402, theprocess400 begins with thevehicle102 identifying an initial connection between thevehicle102 and the mobile device104 (e.g., the mobile device104-B of the scenario200). This initial connection may be, for instance, via BLE.
• At operation404, thevehicle102 identifies that pairing is desired using thekeypad118. For instance, if theNFC sensors114 are not functioning properly or too much interference is present, the user may choose to input the BLE confirmation code through thekeypad118 instead. This may be signified with a unique double button press (e.g., the user pressing both the1 and the3) to inform thecontroller108 of BLE pairing mode. This unique press may be followed by transmission of the BLE confirmation code from theBLEM112 to thecontroller108. Or, in other examples, when performing out-of-band pairing it may generally be necessary to input a confirmation code via thekeypad118.
• Atoperation406, thevehicle102 sends information indicative of which digits of the keycode are even and which digits are odd to thecontroller108. This may allow for thecontroller108 to receive the keycode to thebuttons120, which do not distinguish between even and odd values. Moreover, in only indicating the evenness/oddness (e.g., the least significant bit of each digit), the keycode may remain relatively secret. In some implementations, thecontroller108 only interprets the values of theexternal button120 presses by their positions (e.g., 1-5 rather than 0-9) theBLEM112 may signify to thecontroller108 which code digits are odd/even when the confirmation code is first generated (e.g., which may be done by the BLEM112). For instance, if the code is “12357”, theBLEM112 may signify that the second digit is even, such that the user's input will always assume the second input is an even value.
• Thevehicle102 sends the received keycode to thecontroller108 atoperation408. In an example, thekeypad118 may receive keypresses to thebuttons120. Thekeypad118 may, in some examples, collect the entire code and send the entire code to thecontroller108. In another example, thekeypad118 may send each digit of the keycode to thecontroller108 and allow thecontroller108 to combine the presses into a complete code.
• At410, thevehicle102 validates the keycode. Accordingly, thecontroller108 may determine whether the code typed into the keypad is allowable for access of the user of themobile device104. If the code is allowable, then access may be granted and theprocess400 ends. If not, then theprocess400 also ends (or reverts back tooperation408 to receive another attempt at the keycode).
• Referring back toFIG. 2, a unique key share access key may be managed by thecloud server130. When PaaK is first configured on thevehicle102, thecloud server130 may send a CAK-like security key to the controller108 (e.g., a code that is much lengthier than the keypad codes that are entered by a user, the code instead having security requirements similar to the CAK). This value may then be deployed to the key share requestor's phone (e.g., the mobile device104-B), such that each subsequent tap after initial connection would transmit the key share access key instead. (For instance, the key share access key may be transmitted as described in theprocess300, with the key share access key sent instead of the CAK). This message provided viaNFC106 may include a header such that theBLEM112 may be instructed to gateway the message to thecontroller108 for unlock validation.
• This key share access key may be also dynamically-generated each time a key share request is made, whereby the key share access key is included with the CAK in the original pairing transmission. The key share access key may then be revocable via a message from thecloud server130 relayed through owner's phone (e.g., the mobile device104-A) once the key share period is over.
• FIG. 5 illustrates anexample process500 for the management of a revocable key share access key. In an example, theprocess500 may be initiated responsive to receipt of the access credentials from thecloud server130.
• Atoperation502, thevehicle102 receives a key share access key to thecontroller108. In an example, the key share access key may be included in security credentials sent to thevehicle102 responsive to the mobile device104-A of a sharing user allowing the mobile device104-B of another user to access thevehicle102.
• Atoperation504, thevehicle102 deploys the key share access key to themobile device104. In an example, the mobile device104-B may perform direct out-of-band pairing to facilitate vehicle access, for example using theprocess300. Responsive to validation of the credentials in theprocess300, thevehicle102 may provide the key share access key to the mobile device104-B, for the mobile device104-B to provide in further instances where the mobile device104-B requests access to thevehicle102.
• Atoperation506, thevehicle102 determines whether the key share access key is revoked. In an example, thevehicle102 may receive a message from thecloud server130 revoking the key share access key. This may be done, for instance, responsive to thecloud server130 receiving a message from the mobile device104-A indicating that the user no longer wishes to allow the mobile device104-B to share thevehicle102. If the key is revoked, control passes tooperation510. Otherwise, control continues tooperation508.
• Atoperation508, thevehicle102 determines whether the key share access key has expired. In an example, the key share access key may expire responsive to a timeout (e.g., predefined for key share access keys, specified by the key share access key, etc.). In another example, the key share access key may expire responsive to the key share access key being used a predefined number of times (e.g., predefined for key share access keys, specified by the key share access key, etc.). If so, control passes tooperation510. If not, the process returns tooperation506.
• Atoperation510, thevehicle102 deletes the key share access key from the controller. Accordingly, the key share access key may no longer be available for authentication of users. Afteroperation510, theprocess500 ends.
• Computing devices described herein, such as themobile devices104,controller108, andcloud server130, generally include computer-executable instructions where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, JAVA™, C, C++, C#, VISUAL BASIC, JAVASCRIPT, PYTHON, PERL, PL/SQL, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media.
• With regard to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.
• Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation.
• All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.
• The abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
• While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.

Claims (20)

1. A vehicle comprising:

a keypad mounted to an exterior of the vehicle, the keypad having a plurality of buttons;

a body controller, programmed to

receive an input sequence entered via the keypad,

validate whether the input sequence matches a predefined keycode, and

confirm pairing a mobile device to the vehicle responsive to the input sequence matching the keycode; and

a short-range wireless controller, programmed to

identify an initial wireless connection from the mobile device to the vehicle,

identify to use the keypad for keycode pairing of the mobile device to the vehicle,

generate the keycode,

send the keycode to the mobile device for display, and

responsive to successful authentication of the mobile device to the vehicle, send a key share access key to the mobile device to be provided from the mobile device to the vehicle for further authentications.

2. The vehicle ofclaim 17, wherein, for each button, the first value is an even number, and the second value is an odd number.

3. (canceled)

4. The vehicle ofclaim 1, wherein the short-range wireless controller is further programmed to identify to use the keypad responsive to receipt of a predefined input to the keypad.

5. The vehicle ofclaim 4, wherein the predefined input is a simultaneous press of a plurality of the buttons.

6. The vehicle ofclaim 1, wherein the initial wireless connection is over Bluetooth low energy (BLE).

7. (canceled)

8. The vehicle ofclaim 1, wherein the body controller is further programmed to receive a message from a cloud server revoking the key share access key, such that the key share access key is no longer available for further authentications.

9. The vehicle ofclaim 1, wherein the body controller is further programmed to expire the key share access key responsive to the key share access key being used for successful access a predefined number of times.

10. A method comprising:

receiving a keycode, including a sequence of values to pair a mobile device to a vehicle;

receiving an input sequence entered via a keypad of the vehicle, the keypad having a plurality of buttons;

validating, by a controller, whether the input sequence matches the keycode;

confirming access responsive to the input sequence matching the keycode; and

responsive to successful authentication of the mobile device to the vehicle, sending a key share access key to the mobile device to be provided from the mobile device to the vehicle for further authentications.

11. The method ofclaim 10, further comprising:

identifying an initial wireless connection from the mobile device to the vehicle;

identifying to use the keypad for keycode pairing of the mobile device to the vehicle;

generating the keycode; and

sending the keycode to the mobile device for display.

12. (canceled)

13. The method ofclaim 10, further comprising receiving a message from a cloud server revoking the key share access key, such that the key share access key is no longer available for further authentications.

14. The method ofclaim 10, further comprising expiring the key share access key responsive to the key share access key being used for successful access a predefined number of times.

15. A method, comprising:

receiving a keycode, including a sequence of values to pair a mobile device to a vehicle;

receiving an input sequence entered via a keypad of the vehicle, the keypad having a plurality of buttons;

validating, by a controller, whether the input sequence matches the keycode;

confirming access responsive to the input sequence matching the keycode; and

responsive to identifying an initial wireless connection from the mobile device to the vehicle, displaying a message indicating the mobile device to be placed against a near-field communication reader of the vehicle to transmit a key to the vehicle.

16. A system comprising:

a keypad mounted to an exterior of a vehicle, the keypad having a plurality of buttons a body controller; and

a short-range wireless controller, programmed to

identify an initial wireless connection from a mobile device to the vehicle,

identify to use the keypad for keycode pairing of the mobile device to the vehicle responsive to receipt, to the keypad, of receipt of a predefined input including a simultaneous press of a plurality of the buttons,

generate a keycode including a sequence of values,

send the keycode to the mobile device for display, and

responsive to successful authentication of the mobile device to the vehicle, send a key share access key to the mobile device to be provided from the mobile device to the vehicle for further authentications,

wherein the body controller is programmed to

receive an input sequence entered via the keypad,

validate whether the input sequence matches the keycode, and

confirm access responsive to the input sequence matching the keycode.

17. The vehicle ofclaim 1, wherein:

each button of the keypad represents both a first value and a second value;

the short-range wireless controller is programmed to indicate to the body controller which values of the keycode are the first value and which are the second value; and

the body controller is further programmed to validate the input sequence assuming the input sequence correctly entered the first value or the second value according to indications of which values of the keycode are the first value and which are the second value.

18. The method ofclaim 10, further comprising:

indicating which of the sequence of values are even and which are odd, each button representing both an even value and an odd value such that it cannot be determined whether an even value or an odd value was entered; and

validating the input sequence assuming the input sequence entered even or odd values correctly according to predefined indications provided to the controller of which values of the keycode are even and which are odd.

19. The method ofclaim 15, further comprising:

indicating which of the sequence of values are even and which are odd, each button representing both an even value and an odd value such that it cannot be determined whether an even value or an odd value was entered; and

validating the input sequence assuming the input sequence entered even or odd values correctly according to predefined indications provided to the controller of which values of the keycode are even and which are odd.

20. The system ofclaim 16, wherein:

each button of the keypad represents both a first value and a second value;

the short-range wireless controller is programmed to indicate to the body controller which values of the keycode are the first value and which are the second value; and

the body controller is further programmed to validate the input sequence assuming the input sequence correctly entered the first value or the second value according to indications of which values of the keycode are the first value and which are the second value.

Images