Gesture Based Touchpad Security System Using Atmega644

Introduction

The purpose of the project is to present a new approach on the design of security systems by using a touch sensitive device. Security is a permanent concern in a variety of environments ranging from physical access restriction in home and industrial settings to information security in digital systems. Numeric passwords, fingerprint recognition, and many other techniques have been extensively implemented in the past but they present certain drawbacks. The proposed technique makes use of a touch device to recognize symbols as passwords and takes time into account to add a new dimension and prevent password theft.
We implemented a prototype that demonstrates the capabilities of the proposed security approach by showing one direct application in physical access restriction systems.

High Level Design

Rationale

Currently, many security systems suffer from a set of drawbacks that make them prone to password theft. More specifically, personal passwords usually consist of a finite set of alphanumeric characters that are easily identifiable by seeing or hearing them. Furthermore, without the appropriate encryption, automated systems can iterate through many combinations and decipher the information. We believe in the idea that passwords should not be based on combinations that can be written, or pronounced, but they should rather be abstract elements that are not easily definable but can be understood on a personal basis.
With this idea in mind, we propose a new definition of password that consists of time-based symbols. Using a touch-sensitive device, a user enters a combination of symbols by using a finger. The dimensions used to represent the password are the shape of each symbol, and the time taken when doing each of the traces. Using this representation, the user is forced to think of and memorize passwords in a more qualitative manner, and is also prevented from using bad habits such as storing passwords in text files.

Previous Work

Gesture based systems are becoming more popular nowadays with the spread of touch-enabled devices. However, little work has been done in the area of security. Some implementations can be found but they fail to provide a secure password representation that is not easily stolen. One popular example is the lock-screen gesture passwords implemented for mobile devices that use the Android operating system. The functionality consists of using your finger to enter a pattern into a grid. While the approach seems similar to our proposed system, it has one serious problem: the finger leaves marks on the phone screen, and those marks are easy to identify and reproduce. Our solution to this type of problem is the addition of the time dimension with which the recognition of the shapes is not sufficient for copying the password.

Logical Structure

Our project is divided into four self-contained entities that are in charge of providing each of the required functionalities of the device. Figure 1 presents the high-level organization and illustrates the interaction between the entities.
The program logic entity is in charge of keeping the state of the system, managing the interaction with the user, instantiating the different entities, and controlling the interaction between them. The touchpad data acquisition unit is in charge of retrieving the finger position and pressure data in a raw format and transmitting it to the main program logic. The gesture representation and matching entity has the purpose of converting the raw data obtained from the touchpad into a logic representation and providing the comparison and matching between different gestures. Finally, the PC management entity provides the administrator with an easy tool to manage the device and look at the system events in real time.

System Specification

From a user point of view, the prototype is composed of a touchpad, two push buttons, two LEDs, and a USB connection.
To enter a password, the user must press the action button, then enter one or more symbols in the touchpad, and then press the action button again to finish the password.
The device can be used by two types of users: a regular user and an administrator. For the regular user, the password entering system is the only visible functionality. Once the user enters a password, the green LED flashes if the password was accepted, or the red one does if the password was rejected. For the administrator, the admin button is also visible and it enables him or her to actually set the password of the device. After pressing the admin button, the administrator is provided with administrator rights, and the next time a password is entered (again, using the action button), it is going to be recorded as the device password. Moreover, the administrator also has access to the usb connection with which the system can be monitored from a computer. Every action in the device, i.e. acceptance or rejection of users, is constantly sent and can be seen in a computer if the connection is enabled. Finally, if the device is connected via USB, the administrator also has the ability to set the password from the computer application, and look at the acceptance/rejection counts.

Hardware/Software Tradeoffs

The device uses only digital hardware elements and therefore the main tasks consist of handling each element with software implementations. All the program logic is implemented in software, and hardware elements are only used for data acquisition, signaling and communication.
In one specific case, however, we decided to use a hardware implementation of a functionality that could have been implemented in software. The functionality is the USB implementation for communicating to the PC application. We could have chosen to implement the USB protocol in the microcontroller and connect it directly to a computer. However, this decision would have increased the development time significantly without adding any extra value to the product. Instead, we decided to use a hardware chip that converts RS232 data into USB, and provides a driver to emulate a COM port in the PC. This way, development efficiency is increased because we are able to implement an easier serial communication on both the microcontroller and the PC side while still using the convenient USB interface in the middle.
We also considered using an LCD in the device to show interface messages such as “Enter password” and “Password accepted”. From the software-implementation perspective, it did not represent any significant change. The tradeoff, in this case, was between cost and usability. Nevertheless, we considered that the device was easy enough so that after using it the first time the user should not need any extra help, and thus the LCD becomes redundant. For this reason, we simply used a couple of LEDs that indicate when passwords are accepted and rejected and saved some costs.

Standards

PS/2

Communication protocol used by certain types of peripheral devices such as mouse devices and keyboards. It’s being replaced by USB but there are still multiple devices that use it nowadays. The Synaptics touchpad we chose uses the PS/2 protocol and therefore we needed to implement it in order to be able to communicate with the touchpad.

USB

Universal Serial Bus. One of the most popular protocols to establish communication between peripherals and host controllers, which are usually computers. In the project, we used USB as an intermediate link between the device and a computer.

Hardware

The following figure illustrates the high-level hardware distribution of the device.

Custom prototype board

We used one AVR Atmega644 microcontroller. For connecting to the microcontroller, we used a custom USB prototype board. The board is meant to be used for next year’s class, and an early version was obtained from Nathan Chun for use by our group. The PCB layout is shown in figure 4, and a schematic is shown in figure 5. The schematic lacks specific details on the USB converter chip and connector because they were unavailable. The board receives power from a wall plug which goes into a 5V regulator, the LM340LAZ-5.0. A switch on the side is used to turn the board on and off, and the microcontroller sits on a socket, from which its pins go out to header pins across the top of the board. A 16MHz crystal generates the clock, and a 1N4001 diode protects the regulator from reverse bias. The UART pins (D.0 and D.1) go to a FT232R USB converter chip, which then goes to a USB connector. The board we used was fully populated with all components, including capacitors, resistors, and all header pins.

Touchpad

We used a Synaptics touchpad whose specific reference is TM41PUM1311-2. At the selection stage, we found that Synaptics provided organized documentation for its older touchpads which could be very beneficial for communicating with the device and thus we chose to look for touchpads with their brand. We found a very cheap touchpad online that had been removed from a Dell laptop, and even though Synaptics did not have specific documentation for that reference, most of the specifications were very general, so we took the chance to try to make it work.