Security Wireless Lock Starts Exchange

Abstract

Systems and techniques for secure wireless lock initiation exchanges are described herein. Upon receiving a request from a device to initiate a lock, a controller may calculate a challenge counter and then perform verification iterations until an end condition is met, i.e., a verification iteration fails or the number of iterations reaches the challenge count. If the verification iterations reach the challenge count (e.g., there are no failed iterations), the controller initiates the lock. Each iteration includes an exchange between the device and the controller that is confirmed by the device signing the message with a private key shared by the device and the controller. The exchange also includes a freshness value that is integrated into the device confirmation to prevent replay attacks.

Description

[0001] Information about divisional applications

[0002] This application is a divisional application of the Chinese invention patent application with application number 201980044037.5, application date June 26, 2019, and invention name “Secure Wireless Lock Start Exchange”.

[0003] Priority application

[0004] This application claims the benefit of U.S. Application Serial No. 16 / 023,309, filed on June 29, 2018, which is incorporated herein by reference in its entirety. Technical Field

[0005] Embodiments described herein relate generally to remote activation of motors or other devices, and more particularly, to a secure wireless lock activation exchange. Background Art

[0006] Wireless mechanisms for starting motors, solenoids, or other devices have been used in a variety of products, such as garage door openers or vehicle locking mechanisms (e.g., unlocking doors, opening trunks, starting engines, etc.). Pairing between an annunciator (e.g., a wireless key-fob) and an initiator (e.g., a vehicle unlocking mechanism) can be used to add security to the process. For example, such pairings typically do not employ complex encryption in order to reduce component costs and extend battery life in the annunciator.

[0007] Rolling codes (e.g., code hopping) may be used to prevent replay attacks that may occur in the case of simple pairing. A replay attack involves recording a previous transmission, such as using a radio receiver near a successfully used annunciator; and replaying that transmission in the future to achieve an unauthorized initiation. Rolling codes help prevent such attacks by defining a sequence of codes, with the next code in the sequence being used for the next initiation attempt. The annunciator and initiator store the sequence and maintain an index into the sequence that increments with each use. Thus, recording a previously used code in the sequence will not be accepted by the initiator because the initiator has moved on to another code in the sequence after successfully using the recorded code. Summary of the invention

[0008] In one aspect, the present disclosure relates to a key fob for secure wireless lock activation exchange, the key fob comprising: a wireless transceiver; and a processing circuit configured to: send a request to a vehicle via the transceiver to activate the lock of the vehicle, the request comprising an identifier of the vehicle; and execute a loop of verifying iterative responses, the verifying iterative responses comprising: receiving, by the transceiver, a response of the vehicle to the last transmission from the key fob, the response comprising: a vehicle signature created by the vehicle from the identifier and a freshness value; and the freshness value; verifying the freshness value, wherein the verification of the freshness value comprises comparing the freshness value with the last freshness value stored on the key fob to ensure that the freshness value is greater than the last freshness value; creating a verified vehicle signature based on a key stored in the key fob, the verified freshness value and the first vehicle signature; and sending the verified vehicle signature to the vehicle via the transceiver, wherein the loop exits when no new vehicle signature is received from the vehicle, and the vehicle activates the lock if the verification is passed based on the verification iterative response, otherwise the lock is not activated.

[0009] On the other hand, the present disclosure relates to a method for secure wireless lock activation exchange, the method comprising: sending a request to activate the lock of the vehicle to a vehicle via a device, the request including an identifier of the vehicle; and executing a loop of verifying iterative responses, the verifying iterative responses comprising: receiving a response from the vehicle to the last transmission from the device, the response including: a vehicle signature created by the vehicle based on the identifier and a freshness value; and the freshness value; verifying the freshness value, wherein verifying the freshness value includes comparing the freshness value with the last freshness value stored on the device to ensure that the freshness value is greater than the last freshness value; creating a verified vehicle signature based on a key stored in the device, the verified freshness value and the first vehicle signature; and sending the verified vehicle signature to the vehicle, wherein the loop exits when no new vehicle signature is received from the vehicle.

[0010] In another aspect, the present disclosure relates to a system comprising means for performing any of the aforementioned methods.

[0011] In another aspect, the present disclosure relates to a machine-readable medium comprising instructions which, when executed by a processing circuit, cause the processing circuit to perform a method according to any of the foregoing methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In the drawings that are not drawn to scale, the same numerals may describe similar components in different views. The same numerals with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate various embodiments discussed herein by way of example and not limitation.

[0013] Figure 1 is a block diagram of an example of an environment including a system for secure wireless lock-initiated exchanges according to an embodiment.

[0014] Figure 2 A flow chart illustrating an example of a lock-to-start exchange implemented by a vehicle according to an embodiment.

[0015] Figure 3 A swim lane diagram illustrating an example message exchange between a key-fob and a vehicle performing a secure wireless lock-start exchange according to an embodiment.

[0016] Figure 4 A flow chart illustrating an example of a method for secure wireless lock initiation exchange according to an embodiment is shown.

[0017] Figure 5 is a block diagram illustrating an example of a machine upon which one or more embodiments may be implemented. DETAILED DESCRIPTION

[0018] The rolling code is susceptible to an attack, sometimes referred to as a rolljam, in which an attacker actively interferes with the starter exchange. The attacker snoops on the frequency to obtain the first code from the annunciator. The attacker also jams the wireless link (e.g., by broadcasting the frequency to raise the noise floor above the annunciator's signal). As a result, the starter receiver does not operate (e.g., does not open the lock) and does not advance the rolling code sequence. If the annunciator attempts to start again, such as when the user presses the "unlock" button on the key fob again because the car doors are not unlocked, the attacker captures the second code, jams the receiver again, and then transmits the first code. Because the starter did not advance the sequence when the first code was initially sent from the annunciator, the starter will accept the first code and operate, thereby advancing the sequence to the second code. Because the attacker has the second code, the attacker can broadcast it later, effectively making the starter operate.

[0019] To address the security issues and related technologies brought about by rolling blocking attacks, this article describes a secure wireless lock startup exchange. This exchange modifies the typical wireless startup technology by introducing a variable number of challenge-response exchanges into each request. Each of these exchanges involves an annunciator and an initiator to prove a secret that enables the other in the exchange to verify whether a given exchange is authorized. The technology is effective because an attacker cannot predict whether a given captured signal from the annunciator will operate the initiator, and therefore cannot effectively capture a signal that will operate the initiator in the future. Further, because the technology can be implemented with hardware that already exists on the annunciator and the initiator, the low-cost components and high energy efficiency typically required by these systems are maintained.

[0020] Additional details and examples are provided below. Although many of the examples relate to vehicle starter systems, other examples with similar operating parameters may also benefit from the described devices and techniques. Example systems may include garage door openers, wireless locks for buildings, and other wireless starters.

[0021] Figure 1 1 is a block diagram of an example of an environment including a system for secure wireless lock-start exchange according to an embodiment. The environment includes a device 130 (e.g., annunciator) and a vehicle 120 having a controller 105 (e.g., a starter controller) that is operably connected to control a lock starter (e.g., such as a motor or solenoid) to operate (lock / unlock) the vehicle lock. Although the example involves a vehicle 120, other systems such as a garage door opener can also be used with the devices and techniques described herein.

[0022] Device 130 includes processing circuitry 135 and machine-readable medium 140, as well as a transceiver for communicating with vehicle 120 using wireless link 125. In one example, machine-readable medium 140 contains a symmetric key that is also held by vehicle 120 (e.g., in machine-readable medium 115). In one example, machine-readable medium 140 is protected, such as via encryption, a trusted platform module, etc.

[0023] Processing circuit system 135 is arranged to perform one or more cryptographic functions. For example, processing circuit system 135 may include an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or an execution unit for calculating hashes, message authentication codes (MACs), etc. In one example, processing circuit system 135 includes hardware support for a monotonic counter that can be used to provide a level of variation (e.g., freshness) to the generated MAC. As described below, this facility supports the device's ability to respond to a challenge posed by controller 105 to start the motor.

[0024] Controller 105 includes processing circuitry 110 and machine-readable medium 115. Similar to machine-readable medium 140, machine-readable medium 115 contains a symmetric key and may be cryptographically protected in a variety of ways.

[0025] The processing circuit system 110 is arranged to respond to the request from the device 130 and to start the motor after a successful challenge-exchange with the device 130. As noted above, the challenge-exchange prevents attacks whereby an unauthorized device can instruct the controller 110 to start the motor. In the following examples, the activated motor activates a lock (e.g., moves a pin, releases a magnet, etc.), such as a door lock, a trunk lock, etc. However, the motor starter can also be used to start other entities, such as starting a vehicle engine, turning on or off a water pump in a building, etc.

[0026] To complete the challenge-exchange, the processing circuit system 110 is arranged to receive a request for activating a lock from the device 130 (e.g., via the wireless link 125). In one example, a portion of the request is a vehicle identification number (VIN) identifier of the vehicle 120. As used herein, a "VIN identifier" can be the VIN itself, a portion of the VIN, or an identifier derived from the VIN. Here, the VIN identifier enables the vehicle 120 to distinguish between a request for it or a request for another vehicle. Other identifiers, such as a serial number, a registration tag, or any unique identification code, may also be used. Here, the vehicle contains a lock that is activated by an electric motor and controlled by the controller 105. In one example, the request is for activating the lock from a locked state to an unlocked state. In one example, the nature of the request (e.g., "open door", "open trunk", etc.) is carried in the open message (e.g., an unencrypted portion) of the request. Thus, for example, the vehicle 120 may include a plurality of different locks or activaters specified by the request.

[0027] Processing circuit system 110 is arranged to calculate challenge count. Challenge count is the variable number of challenge-exchanges to be used for this request. Therefore, challenge count is calculated for each request from device 130. In an example, challenge count is higher than threshold value. Therefore, in this example, challenge count has minimum value. Establishing minimum value helps to establish baseline security for exchange. In an example, challenge count is lower than second threshold value (e.g., maximum value). Setting maximum value can be used to balance efficiency and security. In an example, challenge count is a random number. Here, the random number generator of controller 105 or the random number generator accessible to controller 105 can be used to create challenge count. In an example, pseudo-random generator or technology can be used to calculate challenge count.

[0028] One way to generate pseudo-random numbers involves utilizing cryptographic hardware that is used by the controller 105 to generate the MAC. Thus, in one example, the challenge count can be calculated by selecting a portion of the MAC generated using a key, a portion of the request (e.g., the VIN), and a monotonic counter. This monotonic counter is a secret that is not shared outside of the controller 105 and is used to seed the MAC so that it is different each time it is generated. Thus, in one example, the monotonic counter is incremented each time a request to activate the lock is received.

[0029] In one example, the portion of the MAC used as a random number is selected by comparing bytes in the MAC to a threshold until the current byte being compared reaches or exceeds the threshold. Thus, for example, byte 0 may first be compared to a minimum threshold and possibly a maximum threshold. If byte 0 meets the threshold, the number represented by byte 0 is used as the pseudo-random number for the challenge count. However, if byte 0 does not meet the threshold, byte 1 is tested. This process continues until a suitable (e.g., one that meets the threshold) byte is found in the MAC. Although a linear search is described herein, any type of search through the bytes of the MAC may be used to find a suitable pseudo-random value to use as the challenge count.

[0030] The processing circuit system 110 is arranged to perform verification iterations until an end condition is met. The verification iteration is part of a loop that is repeated until the number of verification iterations reaches or exceeds the challenge count, or a failure condition is encountered. The freshness value is used to modify each iteration and changes with each iteration. In one example, the freshness value is implemented as a monotonic counter that increases with each iteration. In one example, this monotonic counter is a counter different from the counter described above for pseudo-random number generation. In this case, the freshness value counter does not need to be kept secret, and its value can be shared as described below. Otherwise, the following situation will occur for each iteration.

[0031] The processing circuit system 110 is arranged to create a vehicle signature created from a counter and a portion of the request (e.g., a VIN). In one example, the vehicle signature is a MAC generated using a key, a portion of the request, and a freshness value. In one example, the portion of the request and the current value of the freshness value are concatenated (e.g., the value of the monotonic counter is added to the beginning, end, or somewhere in the middle of the portion of the request). However, any combination of a counter and the portion of the request may be used as long as both the controller 105 and the device 130 implement the same technique. Thus, a counter may be appended to the portion of the request, a counter may be XORed to the portion of the request, and so on. Any technique that combines a change in a counter with the portion of the request may be used.

[0032] Processing circuitry 110 is arranged to control transmission of the vehicle signature to device 130. Thus, processing circuitry 110 may direct a transceiver, or include a transceiver, to transmit the vehicle signature to device 130 using wireless link 125. In an example, in addition to the vehicle signature, the current value of the freshness value is also sent to device 130.

[0033] In response to receiving the vehicle signature, processing circuit system 135 of device 130 is arranged to calculate a MAC using a key stored in machine-readable medium 140, a freshness value maintained by processing circuit system 135, and a message (e.g., a portion of the original request) to verify the transmission. In one example, device 130 uses the freshness value sent by processing circuit system 110. In one example, processing circuit system 135 verifies that the received freshness value is greater than the last freshness value. To accomplish this, the last freshness value used by processing circuit system 135 is stored in machine-readable medium 140. This last value is compared to the value sent by processing circuit system 110, and if the value transmitted by processing circuit system is less than or equal to the last freshness value, the exchange is terminated. This prevents a malicious entity from recording a previous exchange and playing the exchange forward to obtain a set of valid future messages for the exchange.

[0034] Once this MAC is generated, it can be compared to the MAC of the vehicle signature. If the two match, the transmission is good. The processing circuit system 135 is arranged to create a MAC by using the freshness value, the key and the vehicle signature to create a reply message (e.g., a verification signature). This verification signature is then sent back to the vehicle 120 via the wireless link 125.

[0035] The processing circuit system 110 is arranged to calculate a local-remote vehicle signature from the vehicle signature. In one example, the local-remote vehicle signature is a second MAC using the key and the vehicle signature. Thus, the first MAC is processed as a message, and by combining the key with the message, a second MAC is created.

[0036] Processing circuit system 110 is arranged to compare the local-remote vehicle signature with the verification signature transmitted from device 130. If the local-remote vehicle signature does not match the verification signature, then a fault end condition is met. The exchange is terminated and processing circuit system 110 does not start the motor. However, if the fault condition is not met, processing circuit system 110 is arranged to end the verification iteration in response to the number of verification iterations reaching or exceeding the challenge count. In this case, processing circuit system 110 is arranged to start the motor (e.g., start the lock).

[0037] Figure 2A flow chart of an example of a vehicle-implemented lock-start exchange 200 according to an embodiment is shown. The exchange 200 is illustrated from the perspective of the vehicle, although a portion of the exchange is completed by a signaling device such as a key fob, remote control, etc. The exchange 200 begins when the vehicle receives a request from the signaling device (operation 205). The request may include an identifier (e.g., a VIN) and a message indicating the purpose of the request (such as opening a door, opening a trunk, opening a hood, starting an engine, etc.).

[0038] The vehicle determines whether to direct the request to the vehicle by comparing the VIN to its own VIN. If the VIN or other identifier being used does not match, the exchange ends; the request is not intended for that vehicle. If the VIN does match, the vehicle prepares for the challenge exchange by defining (e.g., calculating, computing, etc.) the number of messages to be used in exchange 200 (operation 210). The vehicle initializes a loop counter (e.g., to zero) (operation 215).

[0039] The loop counter is compared to the number of messages defined for exchange 200. The loop continues as long as the loop counter is less than the number of messages defined. When the loop counter is equal to or greater than the number of messages defined, the loop exits, the vehicle executes the request (e.g., unlocks the doors in operation 245), and exchange 200 ends.

[0040] While the loop continues, the vehicle creates a message by combining (e.g., concatenating, interleaving, etc.) a freshness value (e.g., a monotonic counter that increments with each iteration of the loop) with the VIN, and then creates a MAC from the message and a secret key shared with the signal device to create a vehicle signature (operation 220). This vehicle signature is transmitted to the signal device along with the VIN and the current state of the freshness value (225). The signal device then takes the message and calculates its own version of the vehicle signature using the message, its own version of the private key, and a freshness value synchronized with the vehicle counter (e.g., via a synchronization mechanism or received from the vehicle). If the signal device's version of the vehicle signature matches the version sent by the vehicle, the signal device creates another MAC using the secret key, counter, and vehicle signature to create a verification signature. For example, the signal device may combine the freshness value and the received vehicle signature to create a new message, and then create the verification signature as a MAC using the secret key and the new message. The verification signature is then transmitted and received by the vehicle (operation 230). The signaling device may also verify that the freshness value provided by the vehicle is valid by tracking the last freshness value used by the signaling device and verifying that the current freshness value is at least greater than the last value.

[0041] At the same time, or in response to receiving the verification signature, the vehicle calculates an expected remote vehicle signature by following the same manner as the signaler: creating a new message from the previously calculated vehicle signature and the freshness value, and then creating a new MAC using the key and the new message (operation 235). This expected remote vehicle signature is compared to the received vehicle signature. If the two do not match, the exchange 200 terminates without activating the lock (e.g., operation 245 does not occur). If the expected remote vehicle signature does match the received verification signature, the loop counter is incremented (operation 240), and the exchange continues as described above.

[0042] Figure 3 A swim lane diagram of an example message exchange between a key-fob and a vehicle performing a secure wireless lock activation exchange according to an embodiment is shown. The key-fob signals a request to unlock the doors to the vehicle (message 305). Message 305 identifies the vehicle by VIN and contains information indicating the purpose of the request.

[0043] Once the message 305 is received, the vehicle may determine how many challenges will be used for this exchange by defining a challenge count (operation 310). The challenge count may be determined by generating a random or pseudo-random value that is at least as large as a first threshold and optionally below a second threshold. Once the challenge count is determined, the vehicle may initiate and control an exit from the iterative message exchange (loop 315).

[0044] Loop 320 includes generating a hash-based MAC (HMAC) and transmitting it from the vehicle to the key fob (message 320). The HMAC is created using increments of a freshness value determined by a monotonic counter on the vehicle, the VIN (or other protocol message), and a secret key. The VIN or other protocol message may also be included in message 320 along with the current freshness value (e.g., incremented for this portion of loop 315).

[0045] The key fob verifies the current freshness value by ensuring that it is greater than the last freshness value used by the key fob (operation 325). If the transmitted freshness value is not greater than the last value used by the key fob, the key fob terminates the loop 315. The key fob may terminate the loop 315 by transmitting a termination message, transmitting a message that does not conform to the challenge exchange, sending message 305 again, or simply terminating the communication. The key fob verifies the HMAC (operation 330), and assuming the verification is successful, generates an HMAC of (the HMAC in message 320) and transmits it back to the vehicle (message 335). The freshness value is added to the HMAC of message 320, and the HMAC of message 335 is completed using the secret key.

[0046] Once received, the vehicle verifies the HMAC of the message 335. If the verification is successful, loop 315 continues until the number of exchanges defined by the challenge count is reached. Then, loop 315 is exited and the vehicle unlocks the doors (operation 345). However, if the verification of operation 340 is unsuccessful, the vehicle does not unlock the doors and terminates the exchange. At this point, the key card will initiate a new exchange via a new request.

[0047] Figure 4 A flow chart of an example of a method 400 for secure wireless lock initiation exchange according to an embodiment is shown. The operations of the method 400 are performed by hardware, such as the hardware (eg, processing circuitry) described above or below.

[0048] In operation 405, a request for activating a lock is received from a device. In one example, a portion of the request is a vehicle identification number (VIN) for a vehicle. Here, the vehicle contains a lock. In one example, the request is for activating the lock from a locked state to an unlocked state.

[0049] In operation 410, a challenge count is calculated. In one example, the challenge count is above a threshold. In one example, the challenge count is below a second threshold. In one example, the challenge count is a random number.

[0050] In one example, calculating the challenge count includes: selecting a portion of a message authentication code (MAC) generated using the key, the portion of the request, and a monotonic counter. In one example, selecting the portion of the MAC includes: comparing bytes in the MAC to a threshold until a current byte being compared reaches or exceeds the threshold. In one example, the monotonic counter is incremented each time a request to activate the lock is received.

[0051] In operation 415, verification iterations are performed until an end condition is met. A verification iteration (eg, each iteration) includes operations 420 to 435, and the iterations are repeated until an end condition is met.

[0052] In operation 420, a vehicle signature is created from the freshness value and a portion of the request (e.g., the VIN). In one example, the freshness value is generated from a monotonic counter. In one example, the monotonic counter is incremented at each iteration of the verification iteration.

[0053] In one example, the vehicle signature is a message authentication code (MAC) generated using a key, the requested portion, and a freshness value. In one example, the current state of the requested portion and the freshness value are concatenated (e.g., the value of a monotonic counter is added to the beginning, end, or somewhere in the middle of the requested portion).

[0054] In one example, the key is a symmetric key present on the device and on the hardware that performs the verification iterations. In one example, the hardware that performs the verification iterations includes a secure storage device in which the key is held.

[0055] In operation 425, the vehicle signature is transmitted to the device. In one example, the freshness value is included in the transmission to the device. In one example, the device verifies that the transmitted freshness value is greater than any previous freshness value received by the device.

[0056] In operation 430, a local-remote vehicle signature is calculated from the vehicle signature. In one example, calculating the local-remote vehicle signature includes calculating a second MAC using the secret key and the vehicle signature.

[0057] In operation 435, the local-remote vehicle signature is compared to the verification signature transmitted from the device. The device derived the verification signature from the previously transmitted vehicle signature.

[0058] The end condition of the verification iteration is that the verification iteration reaches at least one of the challenge count or the comparison (operation 435) determines that the local-remote vehicle signature does not match the verification signature. In response to the device correctly meeting each challenge, the first end condition is reached. The second end condition is that the device does not meet the challenge and the process terminates with failure.

[0059] In operation 440, in response to the counter being equal to or greater than the challenge count, the lock is enabled.

[0060] Figure 5A block diagram of an example machine 500 is shown, and any one or more of the techniques (e.g., methods) discussed herein can be performed on the example machine. As described herein, the example may include logic or multiple components or mechanisms in the machine 500, or may be operated by it. A circuit system (e.g., a processing circuit system) is a collection of circuits implemented in a tangible entity of a machine 500 that includes hardware (e.g., simple circuits, gates, logic, etc.). The component relationships of the circuit system can change flexibly over time. The circuit system includes components that can perform specified operations individually or in combination when operating. In an example, the hardware of the circuit system can be designed to perform specific operations (e.g., hard wiring) unchanged. In an example, the hardware of the circuit system can include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), which contain machine-readable media that are physically modified (e.g., magnetic modification, electrical modification, particles of constant mass can be movably placed, etc.) to encode instructions for specific operations. In the process of connecting physical components, the basic electrical properties of the hardware components are changed, such as from an insulator to a conductor, and vice versa. The instructions enable embedded hardware (e.g., an execution unit or a loading mechanism) to create a component of a circuit system in hardware via a variable connection so as to perform a portion of a specific operation when in operation. Accordingly, in one example, the machine-readable medium element is part of the circuit system, or is communicatively coupled to other components of the circuit system when the device is in operation. In one example, any physical component can be used in more than one component of more than one circuit system. For example, in operation, an execution unit can be used in a first circuit of a first circuit system at one point in time, and can be reused by a second circuit in the first circuit system or a third circuit in the second circuit system at a different time. The following are other examples of these components of machine 500.

[0061] In alternative embodiments, machine 500 can be operated as a stand-alone device, or can be connected (e.g., network connection) to other machines. In the deployment of network connection, machine 500 can be operated as a server machine, a client machine or both in a server-client network environment. In an example, machine 500 can be used as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Machine 500 can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a network device, a network router, a switch or a bridge or any machine that can (in turn or otherwise) execute instructions specifying the operation to be taken by the machine. Further, although only one machine is shown, the term "machine" should also include any collection of machines that execute one or more groups of instructions to perform any one or more methods discussed herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations.

[0062] The machine (e.g., computer system) 500 may include a hardware processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 504, a static memory (e.g., memory or storage for firmware, microcode, basic input and output (BIOS), unified extensible firmware interface (UEFI), etc.) 506, and a mass storage device 508 (e.g., a hard drive, a tape drive, a flash memory, or other block device), some or all of which may communicate with each other via an interconnect (e.g., a bus) 530. The machine 500 may further include a display unit 510, an alphanumeric input device 512 (e.g., a keyboard), and a user interface (UI) navigation device 514 (e.g., a mouse). In one example, the display unit 510, the input device 512, and the UI navigation device 514 may be a touch screen display. The machine 500 may further include a storage device (e.g., a drive unit) 508, a signal generating device 518 (e.g., a speaker), a network interface device 520, and one or more sensors 516, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The machine 500 may include an output controller 528, such as a serial (e.g., universal serial bus (USB)), parallel or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., printers, card readers, etc.).

[0063] The registers of the processor 502, main memory 504, static memory 506, or mass storage 508 may be or may include a machine-readable medium 522 on which one or more sets of data structures or instructions 524 (e.g., software) are stored, which embody or are used by any one or more of the techniques or functions described herein. The instructions 524 may also reside, in whole or in part, in any register of the processor 502, main memory 504, static memory 506, or mass storage 508 during execution thereof by the machine 500. In an example, one or any combination of the hardware processor 502, main memory 504, static memory 506, or mass storage 508 may constitute the machine-readable medium 522. Although the machine-readable medium 522 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) configured to store one or more instructions 524.

[0064] The term "machine-readable medium" may include any medium capable of storing, encoding or carrying instructions executed by the machine 500 and causing the machine 500 to perform any one or more techniques of the present disclosure, or any medium capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples may include solid-state memory, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon-based signals, sound signals, etc.). In one example, a non-transitory machine-readable medium includes a machine-readable medium having a plurality of particles with a constant (e.g., stationary) mass, and is therefore a composition of matter. Accordingly, a non-transitory machine-readable medium is a machine-readable medium that does not contain a temporary propagating signal. Specific examples of non-transitory machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), and flash memory devices); magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0065] The instructions 524 may further be transmitted or received over a communication network 526 using a transmission medium via the network interface device 520 using any of a variety of transmission protocols (e.g., frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile telephone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network (e.g., a wireless network known as a wireless network). The Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of standards; known as ), IEEE 802.16 family of standards), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, and the like. In one example, the network interface device 520 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the communication network 526. In one example, the network interface device 520 may include multiple antennas to facilitate wireless communication using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technology. The term "transmission medium" shall be deemed to include any intangible medium that can store, encode, or carry instructions for execution by the machine 500, and includes digital or analog communication signals or other intangible media to facilitate the communication of such software. Transmission media are machine-readable media.

[0066] Additional Notes and Examples

[0067] Example 1 is a controller for secure wireless lock activation exchange, the controller comprising: a lock actuator for locking and releasing; and a processing circuit system, which is used to: receive a request for activating the lock from a device; calculate a challenge count; perform verification iterations until an end condition is met, for each verification iteration, the processing circuit system is used to: create a vehicle signature from a freshness value and a portion of the request, transmit the vehicle signature to the device, calculate a local-remote vehicle signature from the vehicle signature, and compare the local-remote vehicle signature with a verification signature transmitted from the device, the verification signature being derived from the vehicle signature, wherein the end condition is at least one of the verification iteration reaching the challenge count or the comparison determining that the local-remote vehicle signature does not match the verification signature; and in response to the counter being equal to or greater than the challenge count, activate the lock actuator.

[0068] In Example 2, as the subject of Example 1, the freshness value is generated by a monotonic counter.

[0069] In example 3, as the subject matter of example 2, wherein the verification iteration comprises incrementing a monotonic counter.

[0070] In Example 4, the subject matter of any of Examples 1 to 3, wherein the challenge count is above a threshold.

[0071] In example 5, as the subject matter of example 4, wherein the challenge count is below a second threshold.

[0072] In Example 6, the subject matter of any of Examples 4-5, wherein the challenge count is a random number.

[0073] In Example 7, as the subject matter of Example 6, wherein to calculate the challenge count, the processing circuitry selects a portion of a message authentication code (MAC) generated using the secret key, the requested portion, and the second freshness value.

[0074] In Example 8, as the subject matter of Example 7, wherein, to select a portion of the MAC, the processing circuitry compares bytes in the MAC to a threshold until a current byte being compared meets or exceeds the threshold.

[0075] In Example 9, the subject matter of any of Examples 7-8, wherein the second freshness value is generated by a monotonic counter that is incremented each time a request to activate the lock is received.

[0076] In example 10, the subject matter of any of examples 1 to 9, wherein the vehicle signature is a message authentication code (MAC) generated using the secret key, the requested portion, and a freshness value that changes at each verification iteration.

[0077] In Example 11, as the subject of Example 10, the requested portion is concatenated with the current value of the freshness value.

[0078] In Example 12, the subject matter of any of Examples 10-11, wherein to calculate the local-remote vehicle signature, the processing circuitry calculates the second MAC using the secret key and the vehicle signature.

[0079] In Example 13, as the subject matter of any of Examples 10 to 12, wherein the key is a symmetric key present on the device and on hardware that performs the authentication iterations.

[0080] In Example 14, as the subject matter of Example 13, the hardware performing the verification iterations includes a secure storage device in which the key is held.

[0081] In Example 15, the subject matter of any of Examples 10 to 14, wherein the MAC is generated using a SHA256 hash function.

[0082] In Example 16, the subject matter of any of Examples 1 to 15, wherein the requested portion is a vehicle identification number (VIN) for a vehicle having the lock.

[0083] In example 17, the subject matter of any of examples 1 to 16, wherein the request is for initiating the lock from a locked state to an unlocked state.

[0084] Example 18 is a method for a secure wireless lock initiation exchange, the method comprising: receiving a request from a device to initiate a lock; calculating a challenge count; performing verification iterations until an end condition is met, the verification iterations comprising: creating a vehicle signature from a freshness value and a portion of the request, transmitting the vehicle signature to the device, calculating a local-remote vehicle signature from the vehicle signature, and comparing the local-remote vehicle signature with a verification signature transmitted from the device, the verification signature being derived from the vehicle signature, wherein the end condition is at least one of the verification iterations reaching the challenge count or the comparison determining that the local-remote vehicle signature does not match the verification signature; and in response to the counter being equal to or greater than the challenge count, initiating the lock.

[0085] In Example 19, as the subject matter of Example 18, the freshness value is generated by a monotonic counter.

[0086] In Example 20, as the subject matter of Example 19, wherein the verification iteration comprises incrementing a monotonic counter.

[0087] In Example 21, the subject matter of any of Examples 18 to 20, wherein the challenge count is above a threshold.

[0088] In example 22, as the subject matter of example 21, wherein the challenge count is below a second threshold.

[0089] In Example 23, the subject matter of any of Examples 21-22, wherein the challenge count is a random number.

[0090] In example 24, as the subject matter of example 23, wherein calculating the challenge count comprises: selecting a portion of a message authentication code (MAC) generated using the secret key, the requested portion, and the second freshness value.

[0091] In example 25, as the subject matter of example 24, selecting a portion of the MAC comprises: comparing bytes in the MAC to a threshold until a current byte being compared reaches or exceeds the threshold.

[0092] In Example 26, as the subject matter of any of Examples 24-25, wherein the second freshness value is generated by a monotonic counter that is incremented each time a request to activate the lock is received.

[0093] In Example 27, the subject matter of any of Examples 18 to 26, wherein the vehicle signature is a message authentication code (MAC) generated using the secret key, the requested portion, and a freshness value that changes at each verification iteration.

[0094] In Example 28, as the subject of Example 27, the requested portion is concatenated with the current value of the freshness value.

[0095] In Example 29, the subject matter of any of Examples 27-28, wherein calculating the local-remote vehicle signature comprises: calculating a second MAC using the secret key and the vehicle signature.

[0096] In Example 30, as the subject matter of any of Examples 27 to 29, wherein the key is a symmetric key present on the device and on the hardware performing the verification iterations.

[0097] In Example 31, as the subject matter of Example 30, the hardware performing the verification iterations includes a secure storage device in which the key is held.

[0098] In Example 32, the subject matter of any of Examples 27 to 31, wherein the MAC is generated using a SHA256 hash function.

[0099] In Example 33, the subject matter of any of Examples 18 to 32, wherein the requested portion is a vehicle identification number (VIN) for a vehicle having the lock.

[0100] In example 34, the subject matter of any of examples 18 to 33, wherein the request is for initiating the lock from a locked state to an unlocked state.

[0101] Example 35 is a machine-readable medium containing instructions for a secure wireless lock initiation exchange, which instructions, when executed by a machine, cause the machine to perform operations including: receiving a request from a device to initiate a lock; calculating a challenge count; performing verification iterations until an end condition is met, the verification iterations comprising: creating a vehicle signature from a freshness value and a portion of the request, transmitting the vehicle signature to the device, calculating a local-remote vehicle signature from the vehicle signature, and comparing the local-remote vehicle signature with a verification signature transmitted from the device, the verification signature being derived from the vehicle signature, wherein the end condition is at least one of the verification iterations reaching the challenge count or the comparison determining that the local-remote vehicle signature does not match the verification signature; and in response to the counter being equal to or greater than the challenge count, initiating the lock.

[0102] In Example 36, as the subject matter of Example 35, the freshness value is generated by a monotonic counter.

[0103] In Example 37, as the subject matter of Example 36, wherein the verification iteration includes incrementing a monotonic counter.

[0104] In Example 38, the subject matter of any of Examples 35 to 37, wherein the challenge count is above a threshold.

[0105] In Example 39, as the subject matter of Example 38, wherein the challenge count is below a second threshold.

[0106] In Example 40, the subject matter of any of Examples 38 to 39, wherein the challenge count is a random number.

[0107] In example 41, as the subject matter of example 40, wherein calculating the challenge count comprises: selecting a portion of a message authentication code (MAC) generated using the secret key, the requested portion, and the second freshness value.

[0108] In example 42, as the subject matter of example 41, selecting a portion of the MAC includes: comparing bytes in the MAC to a threshold until a current byte being compared reaches or exceeds the threshold.

[0109] In Example 43, as the subject matter of any of Examples 41-42, wherein the second freshness value is generated by a monotonic counter that is incremented each time a request to activate the lock is received.

[0110] In example 44, the subject matter of any of examples 35 to 43, wherein the vehicle signature is a message authentication code (MAC) generated using the secret key, the requested portion, and a freshness value that changes at each verification iteration.

[0111] In Example 45, as the subject of Example 44, the requested portion is concatenated with the current value of the freshness value.

[0112] In Example 46, the subject matter of any of Examples 44-45, wherein calculating the local-remote vehicle signature comprises: calculating a second MAC using the secret key and the vehicle signature.

[0113] In Example 47, as the subject matter of any of Examples 44 to 46, wherein the key is a symmetric key present on the device and on the hardware performing the verification iterations.

[0114] In Example 48, as the subject matter of Example 47, the hardware performing the verification iterations includes a secure storage device in which the key is held.

[0115] In Example 49, the subject matter of any of Examples 44 to 48, wherein the MAC is generated using a SHA256 hash function.

[0116] In example 50, the subject matter of any of examples 35 to 49, wherein the requested portion is a vehicle identification number (VIN) for a vehicle having the lock.

[0117] In example 51, the subject matter of any of examples 35 to 50, wherein the request is for initiating the lock from a locked state to an unlocked state.

[0118] Example 52 is a system for secure wireless lock activation exchange, the system comprising: a component for receiving a request for activating a lock from a device; a component for calculating a challenge count; a component for performing verification iterations until an end condition is met, the verification iterations comprising: creating a vehicle signature from a freshness value and a portion of the request, transmitting the vehicle signature to the device, calculating a local-remote vehicle signature from the vehicle signature, and comparing the local-remote vehicle signature with a verification signature transmitted from the device, the verification signature being derived from the vehicle signature, wherein the end condition is at least one of the verification iterations reaching the challenge count or the comparison determining that the local-remote vehicle signature does not match the verification signature; and in response to the counter being equal to or greater than the challenge count, activating the lock.

[0119] In Example 53, as the subject of Example 52, the freshness value is generated by a monotonic counter.

[0120] In Example 54, as the subject matter of Example 53, wherein the verification iteration includes incrementing a monotonic counter.

[0121] In example 55, as the subject matter of examples 52-54, wherein the challenge count is above a threshold.

[0122] In example 56, as in the subject matter of example 55, wherein the challenge count is below a second threshold.

[0123] In Example 57, as the subject matter of any of Examples 55 to 56, wherein the challenge count is a random number.

[0124] In example 58, as the subject matter of example 57, wherein the means for calculating the challenge count includes means for selecting a portion of a message authentication code (MAC) generated using the secret key, the requested portion, and the second freshness value.

[0125] In example 59, as the subject matter of example 58, the means for selecting a portion of the MAC includes means for comparing bytes in the MAC to a threshold until a current byte being compared reaches or exceeds the threshold.

[0126] In example 60, as the subject matter of any of examples 58-59, wherein the second freshness value is generated by a monotonic counter that is incremented each time a request to activate the lock is received.

[0127] In Example 61, the subject matter of any of Examples 52 to 60, wherein the vehicle signature is a message authentication code (MAC) generated using the secret key, the requested portion, and a freshness value that changes at each verification iteration.

[0128] In Example 62, as the subject of Example 61, the requested portion is concatenated with the current value of the freshness value.

[0129] In Example 63, as the subject matter of any of Examples 61-62, the means for calculating the local-remote vehicle signature includes: means for calculating the second MAC using the secret key and the vehicle signature.

[0130] In Example 64, as the subject matter of any of Examples 61 to 63, wherein the key is a symmetric key present on the device and on the hardware that performs the verification iterations.

[0131] In Example 65, as the subject matter of Example 64, the hardware performing the verification iterations includes a secure storage device in which the key is held.

[0132] In Example 66, the subject matter of any of Examples 61 to 65, wherein the MAC is generated using a SHA256 hash function.

[0133] In Example 67, the subject matter of any of Examples 52 to 66, wherein the requested portion is a vehicle identification number (VIN) for a vehicle having the lock.

[0134] In example 68, the subject matter of any of examples 52 to 67, wherein the request is for initiating the lock from a locked state to an unlocked state.

[0135] Example 69 is at least one machine-readable medium containing instructions that, when executed by a processing circuit system, cause the processing circuit system to perform operations to implement any of Examples 1-68.

[0136] Example 70 is a device including means for implementing any one of Examples 1 to 68.

[0137] Example 71 is a system for implementing any one of Examples 1 to 68.

[0138] Example 72 is a method for implementing any one of Examples 1 to 68.

[0139] The above detailed description includes reference to the accompanying drawings, which form a part of the detailed description. The accompanying drawings show specific embodiments that can be put into practice by way of illustration. These embodiments are also referred to as "examples" in this article. Such examples may include elements other than the elements shown or described. However, the inventors have also considered examples that only provide those elements shown or described. In addition, the inventors have also considered examples of any combination or arrangement of those elements shown or described (or one or more aspects thereof) for a specific example (or one or more aspects thereof) or for other examples (or one or more aspects thereof) shown or described herein.

[0140] All publications, patents, and patent documents cited in this document are incorporated herein by reference in their entirety, even if individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated references should be considered supplementary to that of this document; for inconsistent usages, the usage in this document controls.

[0141] In this document, as is common in patent documents, the terms "a" or "an" are used to include one or more than one, independent of any other instances or uses of "at least one" or "one or more." In this document, unless otherwise noted, the term "or" is used to refer to a non-exclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B." In the appended claims, the terms "including" and "wherein" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Moreover, in the appended claims, the terms "including" and "comprising" are open-ended, that is, systems, devices, articles, or processes that include elements in addition to those listed after the term in a claim are still deemed to fall within the scope of the claim. In addition, in the appended claims, the terms "first," "second," and "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0142] It should be understood that the above description is illustrative and not restrictive. For example, the above examples (or one or more aspects thereof) may be used in combination with each other. After reviewing the above description, other embodiments may be used, such as by a person of ordinary skill in the art. The abstract is intended to allow the reader to quickly determine the nature of the technical disclosure, and is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the above specific embodiments, individual features may be combined together to simplify the present disclosure. This should not be interpreted as intended to make the disclosed features that are not claimed essential to any claim. Instead, the subject matter of the invention may be less than all the features of a particular disclosed embodiment. Therefore, the appended claims are incorporated herein into the specific embodiments, and each claim itself is an independent embodiment. Therefore, the scope of each embodiment should be determined with reference to the appended claims and the full scope of equivalents authorized by these claims.

Claims

1. A key card for secure wireless lock startup exchange, the key card comprising: Wireless transceiver; and A processing circuit configured to: sending, via the transceiver, to a vehicle a request to activate a lock of the vehicle, the request including an identifier of the vehicle; as well as Execute a loop to verify the iterative response, including: receiving, by the transceiver, a response from the vehicle to a last transmission from the key fob, the response comprising: a vehicle signature created by the vehicle from the identifier and the freshness value; and the freshness value; verifying the freshness value, wherein verification of the freshness value includes comparing the freshness value to a last freshness value stored on the key fob to ensure that the freshness value is greater than the last freshness value; creating a verified vehicle signature based on a key stored in the key fob, the verified freshness value, and the vehicle signature; and The verification vehicle signature is sent to the vehicle via the transceiver, wherein the loop is exited when no new vehicle signature is received from the vehicle, and the vehicle activates the lock if verification is passed based on the verification iteration response, otherwise the lock is not activated. 2 . The key fob of claim 1 , wherein the freshness value is generated by a monotonic counter that increments with each iteration of the loop.

3. The key fob of claim 1 , wherein the loop has an upper limit defined by a challenge count held by the vehicle, wherein the request to activate the lock of the vehicle is successful if a challenge count number of authentication iterations succeeds, and fails otherwise. The key fob of claim 3 , wherein the challenge count is a random number between a first threshold and a second threshold. 5 . The key fob of claim 1 , wherein the vehicle signature is a message authentication code (MAC) generated using a key, a portion of the request, and the freshness value that changes with each iteration of the loop at the vehicle.

6. The key fob as claimed in claim 5, wherein: The key is a symmetric key present on the key fob and on the vehicle.

7. The key fob according to claim 1, wherein: The vehicle identifier is the vehicle identification number VIN of the vehicle.

8. The key fob of claim 1, wherein: The request initiates the lock from a locked state to an unlocked state.

9. The key fob of claim 1, the number of authentication iteration responses being determined by a challenge counter of the vehicle.

10. A method for secure wireless lock initiation exchange, the method comprising: sending, via a device, to a vehicle a request to activate a lock of the vehicle, the request comprising an identifier of the vehicle; as well as Execute a loop to verify the iterative response, including: receiving a response from the vehicle to a last transmission from the device, the response comprising: a vehicle signature created by the vehicle based on the identifier and the freshness value; and the freshness value; verifying the freshness value, wherein verifying the freshness value comprises comparing the freshness value to a last freshness value stored on the device to ensure that the freshness value is greater than the last freshness value; creating a verified vehicle signature based on a key stored in the device, the verified freshness value, and the vehicle signature; and The verified vehicle signature is sent to the vehicle, wherein the loop exits when a new vehicle signature is not received from the vehicle. The method of claim 10 , wherein the freshness value is generated by a monotonic counter that is incremented with each iteration of the loop.

12. The method of claim 10, wherein the loop has an upper limit defined by a challenge count held by the vehicle, wherein the request to activate the lock of the vehicle is successful if a challenge count number of authentication iterations succeeds, and fails otherwise. The method of claim 12 , wherein the challenge count is a random number between a first threshold and a second threshold.

14. The method of claim 10, wherein the vehicle signature is a message authentication code (MAC) generated using a secret key, a portion of the request, and a second freshness value that changes with each cycle of the vehicle.

15. The method of claim 14, wherein the key is a symmetric key present on the device and the vehicle.

16. The method of claim 10, wherein the vehicle identifier is a vehicle identification number (VIN) of the vehicle.

17. The method of claim 10, wherein the request initiates the lock from a locked state to an unlocked state.

18. The method of claim 10, wherein the number of verification iteration responses is determined by a challenge counter of the vehicle.

19. A system for secure wireless lock activation exchange, comprising means for performing the method according to any one of claims 10-17.

20. A machine-readable medium comprising instructions which, when executed by a processing circuit, cause the processing circuit to perform the method of any one of claims 10-17.

Images