Keypad PIN Immobiliser and Anti-Theft Alarm

The problem

Two-wheelers and small EVs are easy targets for theft. An immobiliser that blocks the drive system until the owner authenticates is a simple, effective defence. It must store the secret safely, resist guessing, survive power cuts and fail into a locked state.

Objectives

• Read PIN entry from the 4×3 keypad with masked feedback on the LCD
• Store a salted hash of the PIN in SPI flash, never the PIN itself
• Block the drive output until the correct PIN is entered and lock out after repeated failures
• Sound an alarm on lockout and allow the owner to change the PIN

What you need

Key concepts

Immobiliser

A function that keeps the vehicle's drive disabled until an authorised key or code is presented.

Salted hash

Storing a hash of the PIN combined with a random salt, so that reading the flash does not reveal the PIN directly.

Lockout and back-off

After several wrong attempts, entry is blocked for a growing time, so guessing a 4–6 digit PIN takes impractically long.

Fail-locked

On power-up, reset or a fault, the outputs start in the immobilised state and are only enabled after successful authentication.

Step-by-step guide

1. 1

   Requirements

   Write requirements: PIN length of 4 to 6 digits, masked entry, three wrong attempts trigger a timed lockout that doubles each time, the alarm sounds on lockout, an owner can change the PIN after entering the current one, and outputs are locked at power-up. Define what the immobiliser blocks: the motor driver enable and the output relay representing a drive contactor.

   Checkpoint: A requirements list with at least ten testable items.

2. 2

   Board setup

   Enable the DIP switches for the keypad, LCD, SPI flash, relay, motor driver, LEDs and buzzer. In CubeMX set SYSCLK to 72 MHz, configure keypad rows as outputs and columns as inputs with pull-ups, LCD pins, SPI with a chip-select GPIO for the flash, relay and motor-driver enable GPIOs with locked default levels, and a 10 ms timer. Check the motor driver's enable input on the schematic.

   Checkpoint: After reset, the relay and motor driver enable are off before any code runs beyond initialisation.

3. 3

   Keypad and LCD

   Scan the keypad every 10 ms with debounce. Use '*' to delete the last digit and '#' to submit. Show an asterisk for each digit on the LCD and a short beep per key. Clear the buffer after a timeout with no key presses. Show a prompt such as 'Enter PIN' on line 1 and the masked digits on line 2, and give distinct beeps for success and failure. Ignore key presses while locked out, but show the remaining time instead.

   Checkpoint: Entered digits appear as asterisks, delete works and the buffer clears after the timeout.

4. 4

   SPI flash driver

   Write a driver for the SPI flash: read the JEDEC ID, read data, enable writes, erase a 4 KB sector and program a page, polling the busy bit. Reserve one sector for the immobiliser record holding the salt, hash, failure count, lockout level and a CRC. Write the record to alternate locations so a power cut during a write cannot corrupt the only copy.

   Checkpoint: The JEDEC ID reads correctly and a record survives a power cycle with a valid CRC.

5. 5

   Hashing the PIN

   Add a small SHA-256 implementation. On first use or PIN change, generate a salt from a source of variation such as ADC noise and timer counts, and store the hash of salt plus PIN. On entry, hash salt plus the entered PIN and compare with a constant-time comparison. Clear the PIN buffer after use. Check the SHA-256 code against a published test vector first.

   Checkpoint: The correct PIN unlocks, a wrong PIN does not, and the flash dump shows no readable PIN.

6. 6

   Lockout logic

   Count failures in the flash record so that removing power does not reset them. After three failures, lock entry for a period, doubling it on each further lockout up to a limit. Show the remaining lockout time on the LCD. Reset the counter after a successful entry. Use the RTC or a timer that keeps counting through the lockout, and decide what happens to an active lockout after a power cut. Document the choice, since restarting the timer on power-up would let a thief shorten the lockout.

   Checkpoint: Three wrong PINs lock entry, the lock survives a power cycle and the time doubles on the next lockout.

7. 7

   Outputs and alarm

   On success, enable the relay and the motor driver enable and show a green LED. On lockout, sound the buzzer in an alarm pattern for a set time and flash red. Add a lock key to immobilise again. If a small brushed DC motor is fitted to the motor driver, it should only run when unlocked. Verify the outputs with a multimeter on the relay contacts.

   Checkpoint: Outputs follow the lock state in every case tested.

8. 8

   PIN change and recovery

   Add a menu to change the PIN: enter the current PIN, then the new PIN twice. Define a recovery method for a forgotten PIN, such as a long service code held by the owner, and explain its risks in the report. Refuse weak PINs such as 0000 or 1234, and require the new PIN to differ from the old one. Record each PIN change as an event so the owner can see when it happened.

   Checkpoint: A PIN change works and the old PIN no longer unlocks.

9. 9

   Test and report

   Test every requirement, including power cuts during entry, during lockout and during a PIN change. Estimate how long a brute-force attack would take with your lockout scheme. Document the design, security choices and limits, such as the possibility of bypassing the board's outputs physically. Also describe how a real vehicle immobiliser differs, for example by authenticating a key transponder with the motor controller over an encrypted link, so the limits of a keypad-only design are clear.

   Checkpoint: A test table and a brute-force time estimate are in the report.

Testing & validation

• Correct PIN unlocks and wrong PINs do not
• Failure count and lockout survive power cycles
• No readable PIN in a flash dump
• Outputs locked at power-up and after reset
• Power cut during a flash write leaves a valid record

Expected results

A working keypad immobiliser with a salted, hashed PIN in SPI flash, persistent lockout, alarm and PIN change, controlling the motor driver enable and the output relay.

Take it further

• Add tamper detection with the MPU6050: sound the alarm if the board moves while locked
• Add a Bluetooth unlock from a phone with an HC-05 add-on and a challenge-response
• Log unlock events with RTC timestamps
• Send the immobiliser state over CAN to a motor controller node

Viva and review questions