Modern Cryptographic Firmware

Overview

Trussed®

Modern Cryptographic Firmware

Status

Very much WIP. Actively developed. Unstable APIs.

Resources

Running tests

cargo test

License

trussed is licensed under either of Apache License, Version 2.0 or MIT License at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Comments
  • [RFC] RSA lib integration

    [RFC] RSA lib integration

    This is an "request for comments"-type PR to invite a discussion and iron out the details of the RSA library integration.

    Context

    We've discussed this with the Nitrokey team a while ago (around the end of 2021) and I took a stab at it, then it got paused for several months after this discussion we additionally had with @nickray. Recently @daringer suggested we move ahead anyway, probably in a form of an NK-specific temporary fork, while those TIPs are getting written/implemented. AFAIU this is driven by the desire to have an RSA implementation for NK3, so at least some working solution is valued higher than the ideal one we discussed in that Matrix chat.

    Implemented now

    RSA2K-PKCS_v1.5 signing/verification and the whole necessary set of helper traits (DeriveKey, etc) + tests for them, that work on a PC. I separately was able to run Trussed and the RSA lib's full set of tests on my nRF52832, but haven't yet tried both of them at once.

    Caveats

    The PR is still well WIP and has items to discuss (marked as TODO:alt3r-3go in the code). I've based the general approach on the miracl one (#12) and that proved to be quite useful, so kudos to @nickray for such a nice example. Due to one of the TODOs related to the test infra, tests need to be run one by one for now, at the bottom of this description I'm showing a simple script that can be used for that. I haven't included it into the code, but let me know if it's helpful until I close the TODO.

    All comments, big and small, as well as suggestions on the TODOs are more than welcome.

    Testing script

    #!/bin/bash
    
    set -e
    set -x
    
    clear && RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_sign_verify -- --nocapture --show-output
    RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_generate -- --nocapture --show-output
    RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_derive -- --nocapture --show-output
    RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_exists -- --nocapture --show-output
    RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_serialize -- --nocapture --show-output
    RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_deserialize -- --nocapture --show-output
    RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_sign_verify -- --nocapture --show-output
    
    opened by alt3r-3go 17
  • Inject any key

    Inject any key

    Draft solution for injecting any key material with the specified kind to the Trussed system. Such is required for Nitrokey Webcrypt and OpenPGP implementations.

    Requesting for comments.

    This modification changes the API by adding a new parameter to unsafe_inject_shared_key, and the name of the function does not seem to be apt for that as well . Ideas for improvements:

    • add "imported" attribute to the key, allowing to identify it when used with security critical functions;
    • use separate function in API to not break other clients' uses (revive unsafe_inject_key ?).

    Quick use case example:

    • https://github.com/Nitrokey/nitrokey-webcrypt-rust/blob/6d20c06a1833d496fd4e5c041e7fb8f248e9545a/src/lib/commands.rs#L810-L817
    opened by szszszsz 7
  • Add support for extracting keys

    Add support for extracting keys

    This PR follows what was discussed in https://github.com/trussed-dev/trussed/discussions/36.

    There are two issues to solve:

    • [ ] Migrations: Already created public keys will have the EXTRACTABLE flag off by default, when it should be set, otherwise it will not be possible to serialize them.
    • [ ] What mechanism should be used to serialize a symmetric key?
    opened by sosthene-nitrokey 4
  • Add virtual platform

    Add virtual platform

    This patch adds a virt feature and module with a virtual platform implementation. This platform uses a basic user interface implementation and RAM storage. It makes it easy to run tests without having to implement all required Trussed components. As the TrussedInterchange and the RAM storage cannot be used concurrently, a mutex is used to protect the platform.

    This is based on the platform that was already used in Trussed’s tests (tests/card/mod.rs).

    This PR depends on #28 because of lifetime issues.

    opened by robin-nitrokey 4
  • Fix key confusion

    Fix key confusion

    This PR fixes key type confusions that could happen previously. Because many symmetric operations didn't check the Kind of the key they used, it was possible to use an ECC key for HMAC or AES.

    This PR also prevents using Shared as a key unless it's been through DeriveKey. I don't think this breaks anything deployed (I checked for fido-authenticator.

    I also find it weird that unsafe_inject_shared_secret yields a key of Kind::Shared IMO it should be Symmetric so that it can be used for symmetric cryptography. I feel like right now the distinction between Kind::Shared and Kind::Symmetric doesn't bring anything.

    opened by sosthene-nitrokey 3
  • Run cargo fmt

    Run cargo fmt

    This PR runs cargo-fmt on trussed.

    This creates conflicts with other branches but they can be solved with some bits of git magic. There is a rebased branch for #29 at here

    opened by sosthene-nitrokey 3
  • Relax key kind check in derive_key for hmacsha256

    Relax key kind check in derive_key for hmacsha256

    In #38 [0], we restricted the operations for the hmacsha256 mechanism to symmetric and shared keys. This breaks fido-authenticator because it uses hmacsha256 derive_key on EC keys [1]. This patch relaxes the restrictions to allow all key kinds.

    [0] https://github.com/trussed-dev/trussed/pull/38 [1] https://github.com/solokeys/fido-authenticator/issues/21

    cc @sosthene-nitrokey: I can’t add you as a reviewer, but please have a look.

    opened by robin-nitrokey 2
  • gh-act: build solo2/nk3-fw repos for trussed-main

    gh-act: build solo2/nk3-fw repos for trussed-main

    • patch solo2 using patch.crate-io after checkout
    • don't patch nitrokey-3-firmware for now, as its current upstream uses Nitrokey's trussed git already, change back later
    • checking out multiple repos failed with actions/checkout@v2 might be an issue with act, no problem or issue would keep it that way so it's locally testable
    opened by daringer 2
  • Add UiClient::wink method

    Add UiClient::wink method

    This patch adds the UiClient::wink method that triggers a visible or audible response of the device, allowing the user to identify it. This is for example needed to implement the CTAPHID wink command.

    opened by robin-nitrokey 2
  • Add a `try_into_new_client(self, client_id: &str )` method to Service

    Add a `try_into_new_client(self, client_id: &str )` method to Service

    This method is similar to try_as_new_client except the resulting ClientImplementation owns the Service. This makes it 'static which is useful in many cases.

    This required also implementing Syscall for Service (it was previously only implemented for &mut Service.

    opened by sosthene-nitrokey 1
  • Get Tests Building

    Get Tests Building

    Awesome work on Trussed and Solo Keys. 😄

    I cloned the repo and found the tests wouldn't build. I've made changes to fix this in the most obvious way, and verified that the tests are still passing on my machine.

    opened by Eosis 1
  • Software Authentication Backend / Trussed Pin Management

    Software Authentication Backend / Trussed Pin Management

    This is a first, fully functional prototype for #32 - The following two PRs are required for this PR:

    • basic multi backend functionality: https://github.com/trussed-dev/trussed/pull/41
    • KeyStore consistency change: https://github.com/trussed-dev/trussed/pull/55

    Example of a runner introducing multiple backends for Trussed: https://github.com/Nitrokey/nitrokey-3-firmware/tree/sw-auth

    Example client app which demonstrates pin handling & policy enforcement for key access: https://github.com/daringer/playground-app/tree/sw-auth

    more details will follow...

    opened by daringer 0
  • Add P256 HMAC-based key derivation from the supplied data

    Add P256 HMAC-based key derivation from the supplied data

    Based on the HmacSha256 implementation - the only difference is, that the result is stored as a P256 key, instead of a shared variant.

    As discussed, it would be best in the future to introduce shared implementation across different combinations of hash and resulting key algorithms.

    Requesting for comments / solution suggestions.


    Improvement ideas:

    • Provide a way to connect multiple mechanisms together, without copying the implementation like in this case.

    Current downsides:

    • supplied implementation is almost a verbatim copy of HmacSha256.

    To do:

    • [ ] change the algorithm to seed-based Ed25519 instead
    • [ ] make sure the generated keys are correct - apply proper checks
    opened by szszszsz 2
  • Add multiple (Service) Backends abstraction

    Add multiple (Service) Backends abstraction

    This adds the structure to allow multiple service backends. Essentially the client now has the possibility to choose a order-of-dispatch in its ClientContext. This is an elementary step towards transparent hardware crypto devices like the se050.

    • Extend ClientId to be a proper struct and call it make it a ClientContext (as the name suggests)
    • Fix several concurrency issues during directory traversal using the ClientContext instead of a quasi-global
    • extend all necessary components and reply_to dispatching based on client-chosen service backends
    opened by daringer 1
  • Trial miracl-trussed wrapping

    Trial miracl-trussed wrapping

    The miracl/core library is an option to provide implementations of a wider range of (non-core) algorithms in Trussed.

    While the implementations are definitely "C translated to Rust", and likely not very speedy

    • it's good to have a wide range of algorithms at least for testing purposes
    • this can be a test-bed for how we want to implement "configurable algorithms with configurable backends".

    Adding to solo2 in Trussed adds 14.9K code, 9.9K from miracl32.

    opened by nickray 0
Owner
Trussed®
Modern Cryptographic Firmware
Trussed®
Firmware, application and documentation for the hackathon

eclipsecon-2022-hackathon WORK IN PROGRESS This repository contains software, firmware and documentation for the EclipseCon 2022 hackathon. Bluetooth

Eclipse IoT Working Group 6 Oct 27, 2022
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.6k Dec 30, 2022
A (mostly) pure-Rust implementation of various cryptographic algorithms.

Rust-Crypto A (mostly) pure-Rust implementation of various common cryptographic algorithms. Rust-Crypto seeks to create practical, auditable, pure-Rus

null 1.2k Dec 27, 2022
Sodium Oxide: Fast cryptographic library for Rust (bindings to libsodium)

sodiumoxide |Crate|Documentation|Gitter| |:---:|:-----------:|:--------:|:-----:|:------:|:----:| |||| NaCl (pronounced "salt") is a new easy-to-use h

sodiumoxide 642 Dec 17, 2022
Collection of cryptographic hash functions written in pure Rust

RustCrypto: hashes Collection of cryptographic hash functions written in pure Rust. All algorithms reside in the separate crates and implemented using

Rust Crypto 1.2k Jan 8, 2023
The underlying cryptographic primitives for Manta Ecosystem

manta crypto The underlying cryptography that manta ecosystem relies on. It comes with the following traits: checksum: definitions for message digest.

Manta Network 10 Nov 10, 2021
Secure storage for cryptographic secrets in Rust

secrets secrets is a library to help Rust programmers safely held cryptographic secrets in memory. It is mostly an ergonomic wrapper around the memory

Stephen Touset 165 Dec 22, 2022
Pure Rust implementation of the RNCryptor cryptographic format by Rob Napier

rncryptor Rust Implementation of the RNCryptor spec This library implements the specification for the RNCryptor encrypted file format by Rob Napier. d

null 7 Jun 29, 2022
Pure-Rust traits and utilities for constant-time cryptographic implementations.

subtle Pure-Rust traits and utilities for constant-time cryptographic implementations. It consists of a Choice type, and a collection of traits using

dalek cryptography 196 Dec 13, 2022
Cryptographic Primitive Code Generation by Fiat

Fiat-Crypto: Synthesizing Correct-by-Construction Code for Cryptographic Primitives Building This repository requires Coq 8.11 or later. Note that if

Programming Languages and Verification Group at MIT CSAIL 538 Jan 7, 2023
Cryptographic signature algorithms: ECDSA, Ed25519

RustCrypto: signatures Support for digital signatures, which provide authentication of data using public-key cryptography. All algorithms reside in th

Rust Crypto 300 Jan 8, 2023
the official Rust and C implementations of the BLAKE3 cryptographic hash function

BLAKE3 is a cryptographic hash function that is: Much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2. Secure, unlike MD5 and SHA-1. And secure again

BLAKE3 team 3.7k Jan 6, 2023
Fastmurmur3 - Fast non-cryptographic hash, with the benchmarks to prove it.

Fastmurmur3 Murmur3 is a fast, non-cryptographic hash function. fastmurmur3 is, in my testing, the fastest implementation of Murmur3. Usage let bytes:

Kurt Wolf 13 Dec 2, 2022
Fuel cryptographic primitives

Fuel Crypto Fuel cryptographic primitives. Compile features std: Unless set, the crate will link to the core-crate instead of the std-crate. More info

Fuel Labs 19 Sep 8, 2022
Dexios-Core is a library used for managing cryptographic functions and headers that adhere to the Dexios format.

What is it? Dexios-Core is a library used for managing cryptographic functions and headers that adhere to the Dexios format. Security Dexios-Core uses

brxken 3 Jul 4, 2022
Common cryptographic library used in software at Mysten Labs.

[fastcrypto] fastcrypto is a common cryptography library used in software at Mysten Labs. It is published as an independent crate to encourage reusabi

Mysten Labs 85 Dec 20, 2022
Key derivation and cryptographic signing functionality for Ethereum applications (ethers-rs)

ethers-signer-factory ethers-signer-factory is a Rust crate that provides functions for key derivation and signing of Ethereum transactions and messag

Ilia 3 Sep 27, 2023
Expose various non-cryptographic hashing functions with Digest traits

noncrypto-digests Expose various non-cryptographic hashing functions with Digest traits. This allows users to use any hashing function with the same t

Yuri Astrakhan 3 Dec 9, 2023
A Boring(SSL)-compatible API abstraction for Rust cryptographic implementations.

A Boring(SSL)-compatible API abstraction for Rust cryptographic implementations. What is Superboring? Superboring hides the complexity, diversity and

Frank Denis 7 Dec 29, 2023