Manufacturing progress

PCBWay has finished manufacturing our initial boards but we are having difficulty sourcing enough microcontrollers to assemble the entire initial batch of 100. For some additional cost we’ve decided to have 20 boards made (a single panel) with the microcontroller chips we can get right now and have the rest assembled when we can get more.

Encryption engine

Now that we have integrated the Nettle cryptography library into the Signet HC firmware we are ready to implement the cryptographic engine features we have planned. These are features where a cryptographic task such as decrypting or signing an email or file is performed securely on Signet HC and the results are sent back to the host operating system. These features will be accessible through the client GUI as well as multiple command-line interfaces.

At the end of this update is a link to survey to help us understand what aspects of the encryption engine features are a priority to our users. Please fill it out to let us know.

Command line implementation

Initially we will create our own command-line tool that is capable of invoking all of Signet HC’s cryptographic operations. In the short term this would mean that Signet could not be used with application plugins integrated with GNU Privacy Guard (GPG). We will port some of the most popular plugins (such as those for encrypting email) to use our tool as an initial solution to this problem.

For the longer term we will have to decide between creating a modified version of GPG or implementing the OpenPGP Card specification, which is already supported by GPG. The OpenPGP Card specification is a smart card specification designed for use with OpenPGP (Pretty Good Privacy) and OpenPGP is compatible with GPG. We can make use of OpenPGP Card specification by making Signet HC identify as a smart card reader and emulate the OpenPGP Card functions.

In the following sections we list our take on the pros and cons of each approach.

OpenPGP Card Implementation

Pros:

• Already supported by GPG
• The Gnuk implementation could be
  ported/adapted. Porting would save time is not completely straightforward.
  Gnuk was not designed for our microcontroller and we would need to integrate
  it with all of our other components in a coherent way that conserves memory and
  processing time.

Cons:

• Smart cards are unlocked with PINs but Signet is unlocked with a password.
  Because of this the GPG software may not be able to unlock Signet by itself
  and may later unnecessarily ask for a pin code after Signet is already
  unlocked
• The smart card interface may be too rigid to support everything we plan on
  doing with Signet HC

GPG Modification approach

Pros:

• Our modifications could result in a new device-independent API for key
  storage not tied to the OpenPGP Card specification. Other devices could
  benefit from this API through a more natural integration. The approach taken
  by Gnuk to identify itself as a smart card reader when there is no actual
  smart card is essentially a hack.
• It could be faster to implement since we may only need to modify gpg-agent,
  the simpler backend portion of GPG

Cons:

• Users would have to take extra steps to make sure their plugins and
  command-line environment could locate our modified GPG. We would distribute
  it on a read only volume with the client to limit the inconvenience. If we
  manage to get an alternate device API integrated into GPG this inconvenience
  might not last too long.

Encryption engine survey

We would appreciate your feedback. Please answer this brief survey with regards to the Signet HC encryption engine.

link: https://crowdsupply.typeform.com/to/wzMyi0