Potential integration of NitroKey firmware with Fobnail application (input for Nlnet grant proposal)

[macpijan]

Introduction and reasoning

From very high perspective, Fobnail project aims to develop software/firmware, which can run on some sort of device (likely USB device), which can be plugged in to the computer and perform local attestation of it's state (i.e.: detect whether the certain parts of the system has not been tampered with). Once this is in place, we may imagine more complex use-case scenarios, such us unsealing some secrets only when the system's state is considered trustworthy.

As Fobnail token (reference platform for the Fobnail application) was based on the nRF52840 dongle, and that it would be desirable to run this on some small device in general, it feels natural to consider integration of the Fobnail application as part of the security USB key, such as the NitroKey.

Some more technical details can be found in the documentation, such as:

• Fobnail API
• Fobnail architecture

Questions regarding the current state of the NitroKey firmware

As we consider integration of the Fobnail application on top of the NitroKey firmware, we figured out it would be optimal to ask here (where the firmware creators, and experts in this area are present) some specific questions that could help us to evaluate the feasibility of such effort.

1. How much RAM/flash is left unused on the device, when running the current NitroKey? We've had problems with stack usage on NRF52840, which could be a challenge to integrate Fobnail in the Nitrokey firmware, considering that even more features would be present at the same time.

2. What protocols does NitroKey use to communicate with applications running on PC? What applications are used for communication? Are those applications specific to Nitrokey or do they follow external standards? If you would point us to the most up-to-date source of information, that would be very helpful. Fobnail currently uses Fobnail API to communication with the host, and some form of host application is required. It could potentially be integrated into the existing solutions, or it coulds stick as a separate application.

Questions regarding the potential integration with NitroKey firmware

1. Currently, Fobnail uses CoAP over IP for communication with host. CoAP API is described in Fobnail API documentation. A possible integration scenario would be to use CTAPHID of NitroKey firmware as a transport layer for CoAP (using vendor commands). Can you see any limitations (or other problems), that could make it not viable?

2. Any general recommendations on how we could integrate Fobnail with NitroKey firmware? Should it be integrated as a library into one of the existing applications, or work as a separate application, communicating over IPC with other applications?

3. Fobnail uses custom blink codes for signaling error/success status, as described in the documentation, Do you see any potential problem with integrating these into the NitroKey firmware? Of course, the exact LED codes are not set in stone, and can be potentially adjusted, for the purpose of compliance with existing ones, or other requirements.

Trussed

Since Trussed is greatly used by NitroKey firmware, and Trussed experts are also present here, we decided to discuss it here as well, to keep it in one place. Please not that the specific questions/requests/issues has been raised in the Trussed repository and linked there as well.

1. What is your opinion about using the alloc crate? Fobnail application currently requires liballoc in some places. From here we may guess, that it is not welcome.

2. Could Trussed implement interfaces from RustCrypto? We’d like to have interfaces from the digest, cipher, signature, and rand_core so that the Fobnail code could be more easily ported to non-Trussed platforms.

   • trussed issue

3. We've encountered two main limitations regarding flash storage (Trussed API, and LittleFS in general):

   • there is a limitation (due to the Trussed's IPC buffer) on the maximum file size (see this trussed discussion)
     • Fobnail requires saving a large amount of data (up to 6 KiB for platform provisioning). Currently, to workaround Trussed limitations around file sizes we increased IPC buffer (which caused problems with RAM usage). Is having a POSIX-like API (open/close/read/write/seek) an acceptable solution for file system APIs (this would allow to split file read/writes into multiple Trussed syscalls)? Any suggestions how we could implement such API? AFAIK Trussed has no concept of of handles/file descriptors.
   • each file takes 8KiB of storage, no matter the actual size
     • Fobnail requires each platform to be provisioned. During platform provisioning Fobnail verifies EK certificate to ensure we are communicating with a real TPM. This requires keeping of various EK root certificates from multiple vendors which takes flash storage. Fobnail embeds all certificates from here. Certificates are processed by our build scripts, and embedded directly into the firmware. Initially those were kept in LittleFS, however this quickly drained entire free storage - certificates are too big to be kept as inline files, and LittleFS allocates 2 blocks for each non-inline file, so each certificate takes 8 KiB of storage (even though most of them would fit into the 2KiB space).
   • Any thoughts regarding LittleFS limitations described above? Have you considered replacing LittleFS with some more space-efficient solution?

4. As part of the Fobnail application, we have have developed certificate store manager. We have failed to use the one from Trussed, but it could potentially get merged somehow. The missing features were:

   • missing RSA support (not an issue anymore, as it was recently added to Trussed, AFAIK)
   • lack of certificate chain verification support (trussed issue)
   • limited features, and other problems with parsing of DER certificates (details to be provided)

5. Some other Trussed issues we have reported in the past, but may not be critical for the purpose of integration:

   • https://github.com/trussed-dev/trussed/discussions/19
   • https://github.com/trussed-dev/trussed/discussions/18

[robin-nitrokey]

Thank you for the input! I’ll try to give you some answers off the top of my head. We’ll have to take a closer look at some of these later.

• current state of the Nitrokey 3
  1. RAM usage: I can’t give you an exact figure off the top of my head. We previously had some issues on the LPC55 but not on the NRF52 AFAIR.
  2. protocols: This depends on the applications. Generally speaking, our default for new applications is CTAPHID vendor commands and CCID as a fallback.
     • admin-app: custom CTAPHID + CCID protocol (de-facto Trussed standard), client applications: pynitrokey, nitrokey-app2, solo2-cli
     • fido-authenticator: standardized CTAPHID protocol
     • secrets-app: custom CTAPHID + CCID protocol (based on the Yubikey OATH Protocol), client applications: pynitrokey, nitrokey-app2
     • opcard: standardized CCID protocol
     • piv-authenticator: standardized CCID protocol with some extensions
     • provisioner-app: custom CCID protocol
     • webcrypt: extension of the CTAP2 protocol that can be used from the web browser, see https://github.com/Nitrokey/nitrokey-webcrypt
• integration
  1. CoAP over CTAPHID: Sounds good to me. The only potential limitation would be the maximum message size and the requirements for client applications (not available in the browser, requires root on Windows).
  2. integration: Generally, I would see fobnail as a separate application. Why do you need to communicate with other applications?
  3. LED: From a technical POV, this should not be an issue, but there are some conflicts with existing LED patterns on the Nitrokey 3.
• Trussed
  1. alloc: We already use alloc to implement RSA in software. If possible, we would like to replace it with a heapless implementation at some point though.
  2. RustCrypto interfaces: Sounds good! Would have to investigate if these traits are compatible with the Trussed data structures.
  3. littlefs:
     • maximum file size: We implemented a streaming API as a Trussed extension, currently in trussed-staging.
     • minimum file size: We also encountered this issue and try to work around it by adapting our filesystem layout to the littlefs constraints, e. g. trying to make files suitable for inlining or combining information in one file that could also be split into multiple files.
     • Generally, I don’t see us moving to a different storage implementation because this would be a major breaking change and require a complicated migration mechanism for existing devices.
  4. certmgr: Interesting! I’ll have a look at it. With the new extension mechanism in Trussed, this could also be implemented as a Trussed extension. (For example, RSA support is also implemented in an extension.)
  5. other issues:
     • default mechanisms: Trussed should now work without default features: https://github.com/trussed-dev/trussed/issues/90
     • HW crypto: Trussed has enum variants for RSA (but no implementation per default), and our Backend API should make it possible to integrate HW crypto implementations. In fact, this is one of the topics we are working on with the SE050.

[jans23]

Regarding RAM usage: In the future we want to have the different features (Trussed apps) configurable at run time so that each user can choose which feature she wants to activate or deactivate. This should give more flexibility to provide Fobnail sufficient RAM.

[arturkow2000]

@robin-nitrokey Thanks for a quick response. We need to communicate with other applications to signal attestation state, so that those applications, e.g. fido-authenticator knows whether platform is trusted and allows only a trusted platform to log-in (if so was configured by the user).

[robin-nitrokey]

I see. This is not possible at the moment but should be easy to implement as an extension – either with a generic extension providing a global state, or with a Fobnail extension (probably the better approach).

[robin-nitrokey]

Implementing the standard crypto traits could be achieved with helper structs. Thinking about it a bit more, I’m not really sure how to approach it. If it only wraps the software implementation, there is no big benefit over using them directly. If it should integrate custom backends, it would be much harder to implement.

Regarding the HW crypto, do you have a plan which hardware to use? SE050?