We’ve studied the results of the encryption engine survey we posted earlier this week and determined our initial approach to implementing the encryption features. The survey showed that users had the greatest interest in:

• GNU/Linux
• Multi-platform support
• File encryption
• SSH authentication
• Integrating with GPG via the OpenPGP Card specification

Our first step will be to integrate these features into our GUI and command line tool. This may not be the way most users will interact with the features but it’s good for testing and implementation flexibility. Then we will move on to porting Gnuk into the Signet HC firmware for GnuPG (GPG) integration. We will release first for GNU/Linux and then add support for other platforms shortly after.

For the long term we would like to directly integrate with GPG so that a password can unlock Signet HC instead of the PIN codes used by the smart card specification. Until we can integrate such a change into a major GPG release users will need to unlock their Signet HC with our GUI or command line tool before using it with GPG.

In-Depth Look: Personal Information Database

Signet HC’s personal information database helps users manage their data through two layers of software:

• The low-level software on the device that maintains the database structure
  and handles the storage and retrieval of entries to the client
• The high-level software in the client that parses the database entries and
  provides user interfaces to view and edit them as well as provide other
  data-type specific tasks such as for password management

Database Structure

Signet HC’s personal information database was designed to store any kind of sensitive user data for access within the client GUI or the client’s browser plugin. All data except files is stored in the personal information database, including two-factor authentication data and public/private key pairs. The database is stored in a region of the microcontroller’s internal flash memory to make it difficult to access if the microcontroller’s security protections are enabled. The database is a collection of entries each of which consist of the following:

• A data block that stores the entries fields
• An integer identifier unique to the entry
• A type identifier indicating how the data block should be parsed
• A "mask" array that indicates which parts of the data block require a device
  button press to be transmitted to the client

When the client starts up it requests all of the unmasked data from all of the entries in the database. This is the data that is not particularly sensitive. The client uses this data to allow the user to search and sort database entries. The user can later request to view the full contents of specific entries, which can be done after pressing the device button.

Password Management

The use case we most commonly discuss for the database is password management. At the hardware level, account entries are no different from other entries. What differentiates them in the client is that the client has specialized features for them whereas user created data types have a generic GUI. Here are some of the password management specific features:

• The ability to login to a website by using the USB keyboard interface that
  Signet HC implements. This is accomplished by forwarding the following
  keypresses to the Signet keyboard interface:
  <username><tab><password><tab><enter>
• The ability to generate truly random passwords during account creation
• The ability to share username and password data with the browser plugin. When
  a new page loads the browser plugin queries the client for any accounts that
  match the page URL. If there are and the browser plugin finds a login form,
  then the user can request that the client transfer the login fields so that
  the browser plugin can place them into the login form.

User Defined Fields

The Signet client has three predefined data types:

• Accounts
• Bookmarks
• Miscellany

The accounts and bookmarks types contain the kinds of fields you would expect. It is possible to add user-defined fields to account data however. One common use is to include answers to account security questions.

The miscellany data type has no pre-defined fields. Instead a miscellaneous entry only has a name and a variable number of user added fields:

In addition to allowing the addition of individual fields it is possible to create a new data type that has a set of user specified required fields but also supports the addition of a variable number of extra fields to specific entries.