Project update 5 of 26
Now that Signet has significantly surpassed its campaign goal, it’s time to consider additional features for Signet if support continues to increase. In this update, I’m going to describe some possibilities that I have thought of or that have been suggested to me in campaign questions. At the bottom, there will be a poll where you can select the top two features you are interested in. Data from the poll will be used to select two strech goals, one which will be unlocked at $7k and another which will be unlocked at $12k. The most popular will be unlocked first and will be ready when the devices ship, the second most popular choice will be available three weeks after shipping to ensure the appropriate development time.
This feature would work by making the Signet client also act as a local daemon that the browser plugin could send and retrieve information from. Due to Signet’s physical security policy the browser plugin would only be able to fill in an entry after a press of the device’s button. In most cases this feature would not require the user to search for and select the database entry and field since it could be determined from the current URL and selected text box.
Based on past experience and background research, the most I can develop in the timeframe of the campaign is support for one browser (on all platforms). In the strech goal poll below, you can choose which browser you would prefer to have plugin support for first, Chrome or Firefox. If pledge levels get high enough, I could support plugins for both browsers with the second browser’s support being delayed a few weeks.
In the current design, if someone stole or found your Signet they could manage to retrieve the encrypted database by loading new firmware that would dump the device’s flash memory contents. If your master password is complex enough, your data could still be very secure. It is better still, however, if the attacker can be prevented from downloading the database in the first place.
This feature would enable the microcontroller’s memory protection features to prevent an attacker from loading new firmware through the factory bootloader or via a hardware debugger. Then the only way to load firmware would be through the interface provided by the firmware already loaded on the device which would only accept new firmware that has been digitally signed. The signing key would default to an "Nth Dimension" owned key but the firmware key could also be changed when logged into the device to allow you to write your own firmware.
It would still be possible for an attacker to try to login to change the signing key to access the device but this would be impractical for all but the most guessable passwords since each attempt would require a press of the device’s button and there would be a limit on how soon another password could be tried after a failed attempt.
Presently, when making backups you must select a destination on your file system. If you purchase two Signets and use one as a fallback device, it would be more secure and more convienent to directly transfer the encrypted database from one Signet to another when both devices are inserted at the same time. With this feature you could set the backup target for your primary device to be your fallback device. This would prevent potentially crackable copies of the database from being stored on your computer and you still would be able to recover from losing a device quickly.
This feature would allow Signet to import and export from pass password databases and add a set of command line tools allowing shell users and scripts to query and update Signet’s database without using the Signet GUI.
Now that you’ve read about all the options, go fill out the survey! The survey will close on Wednesday, September 13, 2017 at 5 PM PDT. We’ll announce results shortly thereafter.