View on GitHub

Development of a Secure Wallet

using Qt and the SEcube platform

Download this project as a .zip file Download this project as a tar.gz file

Authors Bio

Digital passwords are among the most sensitive data one person or organization can have. They protect private information ranging from personal files to bank accounts, and if stolen, the consequences can be catastrophic. In this work we develop a Qt application, SECubeWallet, able to secure any number of passwords, relaying on the encryption power provided by the SEcube platform, which uses a software password together with Hardware keys existing in a small and portable device, making the hacking of the secured data virtually impossible. The main additional feature offered is a realistic password strength estimation using the zxcvbn dropbox project.

SECUBE OPEN SECURITY PLATFORM

The core of our implementation is the SEcube Platform.

The SEcube (Secure Environment cube) Open Security Platform is an open source security oriented hardware and software platform, designed and constructed with ease of integration and service-orientation in mind. The hardware part of the platform was originally designed by Blu5 Group1, whereas the software libraries stem from a strong cooperation among international research institutions.

The software libraries and design environment allow developers who are not willing or able to produce the security APIs and protocols themselves to exploit the ready functions provided (currently as APIs and soon as services) within the SEcube platform and experience the platform as a high-security black box.

Hardware device family

The SECube device family comprise three major members:

In our project we used the Development Board provided by the professors, already configured to our needs. For thefinal user the board would be of course too inconvenient to carry, and instead the USEcube Stick would be preferred.

L2 Security APIs

From the user/developer point of view, the APIs have been implemented targeting two nested environments depending on where physically the code runs:

From the architectural point of view, the Host-Side Libraries have been implemented targeting 4 hierarchical abstraction levels, and namely:

L2 can be considered as the merge of two projects: SEfile, concerning data at rest, and SElink, concerning instead data at motion.

SEfile targets any user that, by moving inside a secure environment, wants to perform basic operation on regular files. It must be pointed out that all encryption functionalities are demanded to the secure device in their entirety. In addition, SEfile does not expose to the host device details about what, or where it is reading/writing data: thus, the host OS, which might be untrusted, is totally unaware of what it is writing

QT

Our application’s graphical interface was developed using the Qt framework.

Qt is a cross-platform application development framework for desktop, embedded and mobile. Supported Platforms include Linux, OS X, Windows, VxWorks, QNX, Android, iOS, BlackBerry, Sailfish OS and others. Qt is not a programming language on its own. It is a framework written in C++. A preprocessor, the MOC (Meta-Object Compiler), is used to extend the C++ language with features like signals and slots. Before the compilation step, the MOC parses the source files written in Qt-extended C++ and generates standard compliant C++ sources from them. Thus the framework itself and applications/libraries using it can be compiled by any standard compliant C++ compiler like Clang, GCC, ICC, MinGW and MSVC

Qt creator

For development we used the IDE Qt Creator.

Qt Creator provides a cross-platform, complete integrated development environment (IDE) for application developers to create applications for multiple desktop, embedded, and mobile device platforms, such as Android and iOS. It is available for Linux, macOS and Windows operating systems

Using Qt creator allowed us to implement easily and fast a robust and elegant solution to our problem. Thanks to the multitude of functions specially dedicated to the management of SQlite databases and display tables, we were able to focus or attention to solve other problems and to extend the functionalities of the project.

ZXCVBN: Realistic Password Strength Estimation

An important feature to final users is the possibility to realistically estimate how strong a password is, i.e., how hard could it be for hackers to crack it, as there is no point in using our system to protect weak passwords, that could be easily guessed with brute force attacks.

As it is out of our expertise to develop a reliable function to make this estimation, we preferred to use a trusted project coming from dropbox hackweek event in 2012. The estimator called zxcvbn was originally written in JavaScript aiming for an easy integration with multiple web browsers and OS.

For over 30 years, password requirements and feedback have largely remained a product of LUDS: counts of lowerand uppercase letters, digits and symbols. LUDS remains ubiquitous despite being a conclusively burdensome and ineffective security practice. zxcvbn is an alternative password strength estimator that is small, fast, and crucially no harder than LUDS to adopt. Using leaked passwords, we compare its estimations to the best of four modern guessing attacks and show it to be accurate and conservative at low magnitudes, suitable for mitigating online attacks. We find 1.5 MB of compressed storage is sufficient to accurately estimate the best-known guessing attacks up to 105 guesses, or 104 and 103 guesses, respectively, given 245 kB and 29 kB. zxcvbn can be adopted with 4 lines of code and downloaded in seconds. It runs in milliseconds and works as-is on web, iOS and Android.

To put it in other words, the authors of the project argue that a password like correcthorsebatterystaple (a nonsense English phrase) is more strong than a password like Tr0ub4dour&3, even if the former does not have any upper cases or numbers, and the latter seems more complicated.

People of course choose patterns dictionary words, spatial patterns like qwerty, asdf or zxcvbn, repeats like aaaaaaa, sequences like abcdef or 654321, or some combination of the above. For passwords with uppercase letters, odds are its the first letter thats uppercase. Numbers and symbols are often predictable as well: l33t speak (3 for e, 0 for o, @ or 4 for a), years, dates, zip codes, and so on. As a result, simplistic strength estimation gives bad advice. Without checking for common patterns, the practice of encouraging numbers and symbols means encouraging passwords that might only be slightly harder for a computer to crack, and yet frustratingly harder for a human to remember. xkcd nailed it.

zxcvbn and Qt integration

First of all, we modified the zxcvbn makefile, to remove the unnecessary files and to understand how to proceed with the integration. It is necessary to compile said makefile in order to generate the dictionary used for passwords comparisons and entropy estimation. When we realized integration of the makefile with Qt was really cumbersome because Qt uses a qmake instead of a regular make, we decided to generate the source dictionary offline. Having the source dictionary ready, we included and modified the files zxcvbn.cpp and zxcvbn.h into our project. The modifications were necessary to use C++ libraries instead of C libraries. Finally, with the files already integrated on the project, we just had to use function ZxcvbnMatch(password) to estimate the entropy and give the user a metric about how strong their password is.

Implementation

The basic idea behind our project is: We use the SEfile APIs to encrypt a file containing the passwords the user wants to protect. Said file is encrypted by the SEcube device connected to the computer, and can only be decrypted later if the same device is connected. The encryption/decryption can be done in any computer where an appropriate version of Qt is installed.

A detailed description of the usage workflow, functionalities and components is given below:

  1. The user connects and mounts the SEcube device to the host computer.
  2. The user executes our application SEcubeWallet
  3. The application ask for a master password, which has been previously configured into the SEcube device (in our case is test). The entered password has to coincide with the stored one to allow the login.

After access is granted, the GUI shown in the figure allows the user to:

  1. Create a new Wallet.
  2. Cypher the wallet, close it and delete the regular (insecure) file.
  3. Open an existent cyphered Wallet.
  4. Add/Edit a new entry to an existing Wallet. The user fills the required fields, and for the password there is strength measure feature.
  5. Delete an existing entry.
  6. Launch a web browser and open the selected domain.
  7. Edit the environment variables.
  8. Safe application close.

Device connection

The SEcube hardware devices SEcube DevKit and USEcube Stick can be easily connected to any pc host via USB ports. They appear in the system as a storage volume and need to be mounted in order to be used.

SEcubeWallet execution

The application is executed as any standard QT application. The host pc requires then to have an appropriate version of Qt or Qt libraries installed and configured. To this moment, the version of Qt used for development is Qt 5.8.0.

Secure login

For our project we used the Login dialogue from the example Secure Text Editor provided alongside with the L2 User Manual and shown in the figure. This dialogue opens a secure connection with the SEcube device and as a result a se3 session pointer s is created. This pointer contains all the information that let the system acknowledge which board is connected and if the user has successfully logged in. After the board is connected and the user is correctly logged in, the secure init() function is issued.

Create a new Wallet

Each wallet is stored as a table in a sqlite database, and is protected independently by a password. In this way the application supports multiple users working with the same SEcube device. This can be useful for companies that wish to protect the passwords of all of their employees, but keep their passwords separated from each other. The user enters the desired name and path using the dialogue shown in the figure, based on the example Secure Text Editor.

The database is created with a QSqlQuery and the function query.prepare that allow us to execute sqlite commands. For the managing of the tables, we use a QSqlTableModel which simplifies the process by wrapping the sqlite functions. To display it in a QTableView, we connect the model to the view table, resulting in the flow Sqltable->Model->TableView.

Cypher and close

After the user has finished creating/editing the wallet, the Sqlite Database file containing the passwords needs to be cyphered using the SEcube device. This is possible using the secure open, secure write and secure close functions from the SEfile API. As a result, an encrypted version of the database file is created. Our implementation is based on the example Secure Text Editor. After the file is encrypted we can proceed to close the database, delete the existing plain sqlite file, which is non secure, and close the tableView displaying the information. In this way, we are sure the passwords are safely stored in the encrypted file, and can only be read by the owner.

Open existing wallet

To open cyphered wallets, the Secure File Dialogue from the Secure Text Editor example is used. This dialogue shows the user wallets in the current working directory that where previously encrypted using the connected SEcube device, as in the figure. The user then selects one of the wallets to be opened.

With the selected cyphered file, and using the SEfile API functions secure open, secure read and secure close, a Sqlite file containing the stored passwords is created. Then a database connection to the file is opened and the entries are displayed in a Table View.

Add/Edit entry to wallet

To Add or Edit a new entry to the wallet, the dialogue shown in figure was implemented.

In this dialogue the user enters the required fields username, domain and password. The password has to be entered twice, to be sure is correct. Additionally, using zxcvbn, we estimate its strength and show it to the user with a progress bar. To edit, the user selects an entry, and clicks the edit button. The same dialogue is called, but with a different constructor, that initialize the fields with the current data. To insert data to the tables, we use again our model and the function model->insertRecord(Position, record), and to submit the changes model->submitAll().

Delete an existing entry

To delete an entry, the user just has to select one of the entries in the table and click the delete button. After this a confirmation prompt is shown warning the user an entry is about to be deleted forever. if the user clicks ok, the application proceeds to eliminate the data using the removeRow function from our model.

Launch web browser

If the user wishes to open in a web browser one of the domains in the wallet, it selects an entry and clicks the Launch button. Thanks to Qt function QDesktopServices::OpenUrl(Qurl(string)) we only had to modify the domain field to include http:// in the beginning of the string.

Edit environment variables

This dialogue is intended for advanced users who would like to choose the algorithm and keys used for encryption in the SEcube device. Right now, with the device configuration provided by the professors, only one option is available.

Safe Close

When the user decides to close the application, several actions need to be performed.

Improvements and Future work

Autofill login forms in website

When the user clicks the launch button, not only the selected domain is opened, also, the login forms are autofilled using the stored username and password. We did not implemented this functionality as it requires HTML/CSS knowledge an it is out of the scope of the course.

OS integration

Some OS, like linux distributions running the KDE Plasma Desktop already offer a wallet solution integrated in the system. Merging our project with these existing wallets could be a great feature for some users.

Browser integration

The vast majority of users store their passwords within their preferred web browser, alongside other sensitive information like browsing history and bookmarks. Using the capabilities of the SEcube security platform to protect all that data while maintaining ease of use and transparency to the final user would be a great advance. We did not investigate further in that direction, but we guess it is possible by developing a complement for the most popular web browsers (Firefox, Chrome, Opera) to run together with the main application.