Project status

[arturkow2000]

We would like to ask what is the overall project status and what has to be done before a stable release comes out. We would like to contribute to Trussed development.

[nickray]

Hi Artur

Industry contributions are highly welcome! We're cautious about "stable releases" (as is typical for the Rust ecosystem). Yes, there are parts that are missing, but also: we'd also like to have at least one non-"security key in USB format" use case to ensure our abstractions and designs are sound. It sounds like you may have one :)

Things that are on the table to be done:

• PC implementation of "runner" allowing easier development and testing of Trussed apps
• multiple independent device implementations (ideally, also a microprocessor, not just microcontrollers), e.g. nRF52840 would be a good candidate
• potentially a non-RTIC implementation
• Trussed extensibility: There should be a "baseline" collection of RPC methods, and a "baseline" collection of (optionally available) cryptographic mechanisms, but how do we make it so that projects using Trussed can locally extend without conflict with upstream (e.g., adding a new alg code point for a new algorithm, do we have official/reserved/custom code spaces, do we run a registry, can we reuse registries...)
• abstraction of crypto backend in Trussed to enable HW crypto
• either better abstraction of encrypted storage, or better desktop support for LittleFS
• "build system" to go from "list of apps, specification of crypto implementations" to "firmware bundle" conveniently
• code reviews or even audits (e.g., the core interchange library has unsafe in it)
• documentation!
• tests!
• user and device authentication
• more apps

I just responded to your other discussions, but would be interested in having a synchronous conversation with you (looping in Nitrokey), to understand what kind of products you're trying to build with Trussed, and how best to collaborate. Care to send me an email (nicolas@solokeys.com)?

[arturkow2000]

Hello

As our project (Fobnail) is a fully open-source product we'd like to keep related discussions public, if you don't mind. Fobnail is a device that verifies whether the computer it is connected to is trustworthy (checks what software is running on computer). Intro from Fobnail documentation and our blog posts describe more in-depth what Fobnail is.

Recently we have run into problems with Trussed IPC, so I'd like to discuss a few things about Trussed architecture.

We have to store quite large files, to workaround this we increased MAX_MESSAGE_LENGTH to 8 KiB, at first it worked, but eventually we have run into stack overflows. Could Trussed have a more robust filesystem API? Something closer to conventional APIs, so that we can open the file, get a handle to that file, do some I/O and then close the file? The same API limitation applies to hash APIs: we cannot hash very big buffers.

Also, even if file writes could be split into many Trussed calls, IPC is still very suboptimal. When we want to make a call to Trussed we have to allocate data on the stack, even though we copy that data to IPC buffer later on. We also have to copy entire response. Coudln't the data be constructed directly in the IPC buffer during writes and poken directly from the IPC without implicit copies?

Another problem is that Trussed doesn't implement any of the traits which have become standard in Rust ecosystem, such as rand_core::Rng, digest::Digest to name a few. This causes problems with integration with third-party libraries. Another problem is portability - in the future Fobnail may run on devices which are not Cortex-M, e.g. Cortex-A or other platforms. In that case, Fobnail would
(ideally) run as application under TEE OS and we would directly use TEE OS services for performing cryptographic operations or accessing persistent storage. We'd like Trussed to implement these standard traits so that we could easily support other providers of cryptographic APIs.

Regarding the interchange library, I am concerned with its security. FWIU during data exchange no serialization/deserialization occurs and data is moved verbatim in memory. But what happends if, for example, a rogue application sends an oversized heapless::Vec (oversized size field)? Or let's consider enums, in Rust constructing an invalid enum is considered UB, so rogue application put some data, that would be later on transmuted into enum. This could break Trussed's control flow and possibly cause many other issues.