Preventing Brute Force Attacks on Offline Embedded Authentication Systems
Written by Hari Nair
As access management systems have evolved from traditional locks to advanced smart locks, passcodes are increasingly replacing keys. Majority of the access management platforms in the market today support door code based unlock. At Latch, security is a core value of every product and feature we develop. As we started investigating the security implications of a passcode based unlock, brute force attacks became an immediate concern.
A brute force attack consists of an attacker submitting several passwords in the hopes of guessing the correct one. This form of attack is commonly used to attack systems that use passwords to authenticate users. The attacker can systematically check every combination of passcodes until they guess the correct one. Most systems solve this problem by blocking users after a certain number of attempts or by slowing down an attacker’s ability to authenticate. However, while dealing with a low-power resource constrained embedded access management systems, the challenges are significantly different:
1.Because the system is designed to provide multiple users access to various spaces in a building, blocking authentication was not a viable option since it could prevent individuals from getting inside their homes. Several online platforms solve this problem by using the IP address of attackers or a set of attackers to slow them down. However, offline low-power embedded systems don’t have the means to uniquely identify unknown users.
2. Allowing a user to continue attempting authentication has implications on the power consumption of these battery-operated devices. Constantly trying to unlock will drain the batteries very quickly.
3. Most authentication devices record a log of all authentication attempts. Because the devices are offline, the information must be stored on the device itself. As the number of attempts increase, the more data there is to store on the device. However, there is only limited space available. Most devices solve this problem by using a circular buffer. So an attacker who wants to eliminate older attempts could, in theory, do so by performing more authentications than the device can store.
On the other hand, online authentication systems can track an attack efficiently because they are online. When a service detects an attack, it keeps a log or notifies someone of the activity. The log, however, can be saved in a different service that the attacker can’t reach. As discussed, most low power systems have limited storage that will overwrite previously saved logs. Because they aren’t connected, this system cannot save the log to a different service.
4. Most services with a password-based authentication scheme also have comprehensive displays (graphic user interfaces) to give valid users an instant alert that something is wrong. However, a vast majority of these embedded authentication systems only have number pads and backlights, so they don’t have a GUI to communicate with the user.
Most online authentication systems block authentication or have rate limiting that targets specific users based on their IP address or other identifying factors. Low-power, resource-constrained embedded systems, however, are agnostic and cannot identify users in real time. Our implementation uses a modified rate limiting approach to solve the problem. This solution detects if we are being attacked, makes it theoretically impossible to guess a valid password in less than 10 days, and logs the attack. It also protects all previous logs saved on the device, reduces power consumption, helps identify the attacker, provides an alternative for valid users, and provides specific graphical feedback so the user knows someone has tried to attack their device.
To do this, we restrict access for a malicious attacker if they have unsuccessfully attempted to unlock the door over ‘x’ times consecutively. The number ‘x’ is chosen to allow a valid user flexibility if they unintentionally enter the wrong passcode. However, if a malicious attacker attempts a brute force attack, they would try to unlock the door using all 10 million possible combinations of our 7-digit door codes. Once the number of unsuccessful unlocks crosses the threshold, we move the lock to a Brute Force Prevention mode to make the lock inaccessible for a certain duration (‘z’ mins). At this point, a photo of the attacker is saved on the device along with a log that can be extracted from the device using a companion iOS or Android app.
Entering Brute Force Mode also moves the lock into a low power mode, where all non-essential features like the camera, flash, and logging are suspended. The keypad and backlights, however, remain functional. Suspending the logging service on the device ensures that all previous logs are protected and that all authentication attempts made during Brute Force Prevention mode are discarded. During this time, if an attacker attempts to authenticate, the 5 and 6 keys on the keypad light up and blink twice as an indication that the device is being attacked. If the attack were to be interrupted by a valid user, this indication also notifies the user that the device is being attacked.
After the ‘z’ minute duration, the lock is moved into a Temporary Authentication mode. The user can then attempt to unlock the door three times. If any of the unlocks are successful, the device moves out of Brute Force Prevention mode and resumes normal operation. If not, the lock is again inaccessible for ‘y’ (n X z) minutes, where “n” is the number of times the malicious attacker enters Brute Force Prevention mode. The maximum value of n is three, so the inaccessible duration is capped at 15 minutes.
*current implementation x = 20, z=5, n = no. of times BPM entered (max 3), y = n X z
Mathematical reasoning formed the basis of this design. Because we use 7 digit passcodes, there are 10 million possible combinations. Since the least amount of time it takes to authenticate an unlock is 1 second, trying every possible passcode would take 10 million seconds, or about 115 days without brute force prevention. If there is brute force prevention, after 26 unsuccessful attempts you can only authenticate 12 times per hour. With brute force prevention, it would take roughly 95 years to authenticate all 10 million codes. This calculation, however, assumes that there is only one valid door code. As our locks support 1,650 codes, the effective time to brute force unlock would be the amount of time required to correctly guess one of the 1,650 door codes. Also mathematically, if there are ‘p’ possible answers, and you guessed more than ‘p/2’ of them, you have a more than 50% chance of having guessed the correct answer at some point.This makes the effective brute force time approximately 10 days. This is an acceptable threshold for the threat to be considered insignificant.
So in summary, our lock is capable of detecting a brute-force attack, identifying the attacker and moving itself into a low power mode. It does this while providing a valid user an avenue to get into his/her building. As we scale the number of supported users, this implementation is going to be further tuned. We have a couple of interesting new features we are working on. Watch this space for more.
