BuzzLock
Team members: Rishov Sarkar, Joshua Shafran, Andrew Gauker, and Celeste Smith
The most convenient and secure door lock.
Living in the dorms and having to carry around a key can be annoying. Students lose their keys all the time and they take up space. So with the BuzzLock you can use Bluetooth and/or a BuzzCard** to unlock your door, no key required!
** Any magnetic stripe card can be used for authentication. **
Presentation Video
Demo Video
Components Used
- Raspberry Pi 3
- Adafruit 7” 800x480 HDMI Backpack (+AR1100 Touch Controller)
- HS-422 Servo
- Magnetic Stripe Card Reader
Schematic and Block Diagram
Schematic with servo connecting to Raspberry Pi
Block diagram of all component connections
Code Description
Our GUI is implemented with Windows Forms (.NET/C#) and designed in Microsoft Visual Studio. Mono is used to open the GUI on the Raspberry Pi. We used C# for the base functionality, along with SQLite for the backend database to store user data during runtime and across power cycles. Unosquare’s soft PWM function was used to control the servo for opening and closing the lock. The automatic on-screen keyboard for editing text fields such as name, phone number, PIN, etc. is provided by calling xvkbd using shell calls directly from C#.
The USB magnetic stripe card reader acts as a keyboard. We use the unique formatting of magnetic card strings to identify a card swipe during any point in the program’s execution.
Authentication Methods
For ultimate security, we enforce a two factor authentication system in which users can unlock the door by combining two out of three different authentication methods: swiping a card, entering a pin, and coming into range with a recognized Bluetooth device. Users are permitted to change their authentication methods any time they access the system.
Permissions system
For finer granularity in who is able to use the system, we have a permission system. There are currently 3 possible permission levels a user may have:
- NONE: Cannot unlock the door or access the options menu, but their information is stored in the database.
- LIMITED: Can unlock the door and access the options menu, but cannot change other user’s information.
- FULL: Can unlock the door, access the user management system, and change any user’s information.
The first user to initialize the system receives a FULL permission level. Subsequent users receive NONE permissions by default, though a user with FULL permission level can later upgrade a user’s permission level.
State Diagram
The program is implemented as a state machine with 11 states, whose diagram you can see below. During runtime, each state transition updates the GUI accordingly.
Windows Forms
In further detail, we approach this problem with an object oriented mindset. We created 4 Windows Forms: FormBuzzLock (a base class from which our 3 other forms inherit), FormStart, FormOptions, and FormUserManagement, which carry out the state machine’s execution.
- FormStart implements all the states in which the door is locked.
- FormOptions allows users with LIMITED permissions to change their name, phone number, and authentication methods.
- FormUserManagement allows users with FULL permissions to edit any user’s profile, authentication methods and permissions, in addition to adding and removing users.
Backend
The backend uses a SQLite database for persistent storage using the System.Data.SQLite library.
We have detailed documentation of the classes and methods used in our backend available at this website.
Authentication
Authentication is performed by using the concept of an AuthenticationSequence. An AuthenticationSequence will Start with the first AuthenticationMethod the user presents, such as a Card or a BluetoothDevice.
If the AuthenticationMethod is recognized as belonging to a User, the AuthenticationSequence indicates what should be the NextAuthenticationMethod the user presents, such as a Card, BluetoothDevice, or Pin. This will Continue until the user has been successfully authenticated.
In our system, we use this paradigm only to implement two-factor authentication, but the concept is powerful enough to implement authentication systems of any desired complexity. For instance, one could design an authentication system that requires only one authentication method of one type or two authentication methods of two other types.
For details on this authentication system, see our AuthenticationSequence documentation here.
Bluetooth
We make use of the BlueZ library to provide Bluetooth functionality. We use a combination of methods to ensure maximum reliability for all Bluetooth use cases with minimal UX friction.
- In SCANNING mode, used when adding a new user or Bluetooth device, device discovery is performed using the BlueZ D-Bus API. Any discoverable Bluetooth device is available in this mode.
- In MONITORING mode, used for checking when known Bluetooth devices are nearby, we spawn l2ping processes to keep open Bluetooth connections to each known device. We then use the P/Invoke facility to call a C function to read the RSSI for each connection to determine how near the device is to the lock.
Our system maximizes ease of use by never requiring the user to pair or connect to the smart lock device. The software simply detects the presence of the device using the methods described above.
For documentation on these Bluetooth modes and how to use them, see our documentation for the BluetoothService class here.
Servo
When the user reaches the authenticated state the servo will rotate clockwise using Unosquare’s wiring pi software PWM function on GPIO pin 13. Upon reenterance to the idle state or all the users are deleted the servo will rotate the opposite way, returning to a locked state. The servo lock vs unlock functionality can be see in the red and green highlighting in the above state diagram.
User Instructions
The Buzzlock goes through a series of setup stages when it is first set up. The steps for use are outlined below.
This is where a user will start when no users have been added. There are instruction to swipe their card and are taken to the initializing state.
Initialization
This screen allows the owner of the system to input their information and preferences. Clicking the ‘Save’ button will save the user to the database.
Duplicate Authentication Method
If a card or Bluetooth device is already registered to a user in the database it is not allowed to be associated to a new user in the user set up screen.
Idle
The screen will now be in idle until a primary authentication method (card swipe or Bluetooth selected) is performed. If the primary authentication method is already in the database, the user will be prompted for a secondary authentication method. If the primary authentication method is not known, the user will be prompted to create a new account.
Second Factor
When a known primary authentication is performed one of the above screen will be shown asking for their second authentication method (card or pin). Bluetooth will be automatically detected so no action is required. The user has three tries total to correctly enter their secondary authentication method.
Authenticated
Upon correct entry of the secondary authentication method and sufficient permissions (full or limited), the user will be able to open the lock. From here, the user has the ability to enter the options menu or lock the door immediately. If no action is taken, the door will automatically lock in 10 seconds.
Options — Limited User
A user with limited permissions can edit fields such as name, phone number, and authentication methods related to their profile as well as delete their profile.
Options — User Management
A user with full permissions is able to add, remove and adjust any user profile within the database from the options menu. They can also delete all users by deleting themselves. This will direct them back to the uninitialized screen, the system will be reset.
Access Denied
If a user with no permissions logs in they will be shown the access denied screen. This screen will also apprear if the second factor is entered incorrectly three times.
Future Work
This semester came with significant limitations, but we have many ideas for future expansions on the project:
- Have users with permissions “FULL” be notified by text message or email when a user with permissions “NONE” attempts to enter the system
- Implement encryption of user data and other security features
- Connecting it to a real apartment door lock
- Implementing a logging system of every attempt to access the system (audit log).
- Sensing when the door is actually closed to better synchronize the auto-lock feature
- Screen sleep until motion is detected
- Enable the ability for the user to add a profile picture using the Raspberry Pi Camera
- Allow user management through text message
- Allowing a limited user access only during certain times of the day