The campaign is entering it’s last few days and we are excited about the next steps. If you’re planning on pledging it will be best to do so during campaign to get your Signet HC made in the first production batch and receive it earlier.

In the process of testing Signet HC’s FIDO2 implementation we discovered that when we used it with all of the original Signet functionality present the program code size exceeded the 128 KB limit we set for it, requiring us to make the Signet database smaller to proceed. Unfortunately this means that we wont be able to port of the FIDO2 features on the original Signet. This result has also required us to think of a new way to store the Signet HC database. We have come up with a new database storage scheme that uses the eMMC to store most data and this scheme has several advantages.

Signet HC database storage scheme

Our design goals:

• Greater database storage capacity than the original Signet
• As difficult to crack as the original Signet
• At least 64 KB new free space on MCU to store code for new features

The original Signet used the microcontroller flash to store the database. This meant that if the microcontroller was locked down it would not be even possible to even access the encrypted database without successfully attacking the MCU at the electrical level. To achieve a similar level of security level in our new scheme we will store the database completely in the eMMC however it will be secured in a similar manner as an encrypted volume — with a set of randomized encryption keys stored in the MCU flash. Each 16KB block of the database will be encrypted with a different AES-256 key. We will store enough keys in the MCU to encrypt at least an 8 MB database. That is 32 times larger than Signet’s 256 KB database. The key randomness combined with the use of cypher block chaining should make decrypting the eMMC blocks by themselves incredibly difficult. This system will require at most 32 KB of the MCU’s flash, leaving an additional 256 KB of additional space for new code.

Dynamically sized primary volume

With the database moving to the eMMC we decided it would be best if there was a primary volume which was integrated with the database rather acting as a separately managed volume. This volume will be used to store files linked to database entries or as a standalone storage system. The primary volume will be a physically secured volume meaning that it will not be directly exposed to the OS and will have similar security features as Signet database entries do such as tags and (optional) button press access requirements.

We have realized that this new primary physical volume will not need to have a definite size. Instead it can automatically occupy unused 32 MB blocks as needed and return them for use by other volumes when possible. It will be easier for the primary volume to dynamically shrink and grow than a conventional file-system since blocks are not mapped linearly in Signet HC. Once a block is no longer used by the primary physical volume it can be later reassigned to any part of another volume. With this design change most likely users wont need to create any alternate physical volumes and will simply take advantage of the primary physical volume’s dynamic sizing.