Welcome To PARSEC

Security for the Infrastructure Edge



PARSEC is the Platform AbstRaction for SECurity, an open-source initiative to provide a common API to hardware security and cryptographic services in a platform-agnostic way. This abstraction layer keeps workloads decoupled from physical platform details, enabling cloud-native delivery flows within the data center and at the edge.

Read the Parsec documentation online.

Read the whitepaper ****.

Why PARSEC?

Use Parsec when you need:

  • A portable interface to your platform's Root of Trust in order to manage keys and perform cryptographic operations without knowledge of the hardware.
  • A simple and portable way to access the best available security of your platform in your preferred programming language.

What PARSEC Provides

The value proposition of Parsec is that it provides the following:

  • Abstraction – a common API that is truly agnostic and based on modern cryptographic principles
  • Mediation – security as a microservice, brokering access to the hardware and providing isolated key stores in a multi-tenant environment
  • Ergonomics – a client library ecosystem that brings the API to the fingertips of developers in any programming language: “easy to consume, hard to get wrong”
  • Openness – an open-source project inviting contributions to enhance the ecosystem both within the service and among its client libraries

Maintainers

PARSEC is a collaborative project. The current list of the individuals and organizations who maintain this project can be found here.

Partner Organizations

See who is using and contributing to PARSEC.

Getting Started

If you are running on x86 Linux, check out this guide to get started with Parsec quickly!

For examples of how to access PARSEC as a client application, check this Rust client documentation.

Check the user, client developer and service developer guides for more information on building, installing, testing and using Parsec!

Community

Come and ask questions or talk with the Parsec Community in our Slack channel or biweekly meetings. See the Community repository for more information on how to join.

Contributing

We would be happy for you to contribute to Parsec! Please check the Contribution Guidelines to know more about the contribution process. Check the open issues on the board if you need any ideas 🙂!

License

The software is provided under Apache-2.0. Contributions to this project are accepted under the same license.

Issues

Collection of the latest Issues

anta5010

anta5010

3

It's now possible (and recommended) to configure Parsec PKCS11 provider with a PKCS11 token serial number instead of a slot ID.

When I tested this feature with a Nitrokey HSM module I initially got an error:

After some debugging and reading specs I found that the serial number must be 16 characters long and must be padded with spaces: http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html#_Toc416959687

I fixed my issue by updating Parsec config with serial_number = "DENK0102227 "

pkcs11-tool -L doesn’t print the trailing spaces which can cause confusions like I had.

So, we can resolve the issue with either:

  1. Strip trailing spaces from both serial numbers when we do this comparison https://github.com/parallaxsecond/parsec/blob/f302e272a24f3408d8008fa6ccb0c192c199f9de/src/providers/pkcs11/mod.rs#L527 or
  2. We update config file parsing procedure and generate an error when serial_number is shorter than 16 chars. The Parsec config file template should also include details about serial_number length requirements and padding with spaces.
ionut-arm

ionut-arm

bug
0

The handling of the admin-set maximum buffer size (for responses) is inconsistent - some operations perform the check (e.g., psa_generate_random in the MbedCrypto provider), others do not (e.g., psa_generate_random in the TPM provider). Ideally, this should be checked consistently, for every (successful) response about to be sent out. We need to figure out if we want to impose this check on other buffers as well (for example, on the output of symmetric encryption or decryption operations).

anta5010

anta5010

0

When there is an issue with creating a PKCS11 provider Parsec doesn't provide enough information about what went wrong even with the "trace" log level. It would be nice to include additional details if possible.

For example,

  1. when an incorrect slot is set in Parsec config for an USB HSM module we only see:

  2. When a Software HSM is used and correct permissions are not set to allow parsec account to access /var/lib/softhsm/tokens/* we only see:

ionut-arm

ionut-arm

bug
2

The issue

Disconnecting and reconnecting a pluggable PKCS11 token leads to the PKCS11 provider being inaccessible. To reproduce the issue:

  • start the Parsec service with the PKCS11 provider and a pluggable hardware backend (e.g. a NitroKey HSM)
  • unplug the hardware backend
  • attempt to create a key using the parsec-tool, you'll get:

This is as expected.

  • plug the hardware back in
  • attempt to create a key again, you'll get

This error is NOT expected. The service should continue to operate correctly in this case.

Solution

There are still bits of information missing which will require some more investigation. I'm hoping to get a way to reproduce this using SoftHSM2.

The ideal solution would be for us to simply re-establish a functional connection to the hardware token when we detect that the token has been unplugged and plugged back in. The actual solution will depend on how reliably we can tell whether this has happened and on what options we identify for re-establishing that connection in a clean way.

Outstanding questions

  • What exact error is received after the device is plugged back in? Is this error sufficiently distinctive to identify this exact cause?
  • Do we attempt to re-establish the connection at provider level (i.e., initializing a new PKCS11 context), or do we restart the whole service somehow? Does it matter if we have other providers involved?
  • If we re-establish the connection at provider level, do we retry the operation that made us realize something's broken? Or just send back something akin to "retry later"?

This is a variant of the more generic approach discussed in #607

ionut-arm

ionut-arm

enhancement
0

Problem statement

At the moment providers are unaware and unbothered by the physical state of the hardware they depend on. They identify and probe the relevant hardware at service startup time, establish a (long-lasting) context with the hardware, and then operate under the assumption that the context will remain valid as long as the service is running. This last assumption is at least somewhat divorced from physical reality, where physical PKCS11 tokens (for example) could be unplugged and plugged back in. In such circumstances, the most likely outcome is that the service becomes unusable, returning errors for every request that actually tries to interact with the hardware. This applies to TPM, PKCS11, and possibly CAL providers - some level of state is cached within the service.

Solution space

There are a couple of possible solutions for this problem.

  1. Don't cache any state. Instead, re-establish the connection for every request. I'm unsure whether this is even possible for all of the providers - for PKCS11 at least, I think, it's not recommended (perhaps not even possible) to have multiple (independent) instances of the context object within the same app. For TPMs we'd have to make all the calls single-threaded or keep track of whether an AB/RM is in use, otherwise the service might lock up. It's also very heavyweight in some cases: for TPM we need to start up the context, create a new session, create a primary key, then tear everything back down.
  2. Try to identify whether the hardware is ok, and if something seems to have gone awry try to recycle the connexion. This is more feasible, but it also comes with its own issues: do we run these checks regularly, or do we just try to identify error codes that might indicate an issue? Can we even identify such a failure? We'll need provider-specific answers to these.

I think only option 2 is viable, but comes with some important design questions attached, and most likely with quite a bit of engineering to make it work. Some of the relevant questions: What do we do if we've set up the connexion again but we get the same error? Do we have some sort of back-off mechanism? Do we put the provider in some sort of "zombie" state while it's like this, responding to all requests with the same response code? Which bits of all this should be configurable?

Testing

We'll obviosly need to test this, and the tests themselves might require some investigation around, e.g., SoftHSM2 and tpm_server, in order to properly simulate a "disconnect" while the service is running.

ionut-arm

ionut-arm

enhancement
1

As mentioned here and here, some PKCS11 tokens allow (or even require) PINs that do not conform to the spec, e.g., containing null bytes. The functionality has already been added (but not released, as of writing this) in the Cryptoki crate to allow such PINs, however this needs to be plumbed up into Parsec.

The authentication value config options for the TPM provider can stand as examples of how this could be implemented, namely by allowing the passed value to take the form hex:..., and to default to treating it as a string otherwise.

Any implementation should be accompanied by configuration tests.

ionut-arm

ionut-arm

security
0

Our current spiffe dependency version has given rise to a few issues flagged by cargo-audit (see this advisory). A new version of rust-spiffe has recently been released which fixes these issues, however from a very brief attempt at updating our Cargo.lock, it doesn't seem straight-forward as a version clash exists around zeroize, due to a requirement in psa-crypto. A new version of the psa-crypto crate might thus be required as well.

Once the spiffe dependency is updated, the .cargo/audit.toml file should also be updated to reflect the fixed issue, and the advisory linked above should also be updated with the relevant information about the affected service versions.

paulhowardarm

paulhowardarm

platforms
0

Summary

In this PR we made Parsec less strict about the PKCS#11 spec when returning the public portion of elliptic curve keys. This was to resolve an interoperability issue with a PKCS#11 library that was not precisely following the spec. In the code review, we discussed adding some additional validity checks to make sure that the data being returned is in fact a valid EC public key and not garbage.

Detail

Probably the most sensible approach is to refactor the existing handle_ecc_public_import_attrib() function, which already contains some of the checks that we need. The checks themselves could be factored out into a validate_ecc_public_key_data() method (or some other suitable name). As inputs, this function would take the key data and the key size (in bits). This function can then be used in common both when importing and exporting.

ionut-arm

ionut-arm

bug
0

Both the on-disk and the SQLite KIMs store files on disk, be it individual entries for each key for the on-disk KIM, or one single file representing all the KIM data for the SQLite KIM. The permissions on these files have not been properly locked down, though - at the moment, all such files allow any user capable of reaching the files to read them. This is mitigated by having the files under /var/lib/parsec, which does not give any permissions to "other" users, thus preventing anyone other than the parsec user and group to access anything within.

Ideally these files (and their host directories) would have similar permissions, though: read and write (and execute, for directories) for the parsec user and group.

If possible, a unit test should be implemented to verify the permissions.

ionut-arm

ionut-arm

enhancement
0

Add support for creating and importing MAC keys in the TPM provider, as well as for generating and verifying MACs.

The expected tasks:

  • Add support in the TransientKeyContext in tss-esapi for creating and importing MAC keys
  • Add support in the TransientKeyContext in tss-esapi for creating and verifying MACs
  • Add the bridging functionality in Parsec to make use of the support mentioned above
ionut-arm

ionut-arm

enhancement
0

Similarly to all the other crypto operations, we should have enough tests to verify both successful and failure cases for MAC creation and verification.

The following should be added:

  • framework for creating and importing MAC keys
  • framework for generating and verifying MACs
  • test for creating and importing MAC keys
  • tests for generating and verifying MACs
ionut-arm

ionut-arm

medium
0

Following #588, add support for MAC operations (psa_compute_mac and psa_verify_mac) in the Mbed Crypto backend. Also verify that the types of keys needed for MAC creation/verification can be created and/or imported.

MohamedAsaker

MohamedAsaker

2

Multi-part operations might be useful, especially for users that transfer and receive data on multiple transactions. Also, this will allow the processing of messages/data that cannot be assembled.

  • Assess the added value of the Multi-part operation to Parsec
  • Assess the effort needed
ionut-arm

ionut-arm

code health
0

Following this report of a build issue for armv7 targets within the rust-cryptoauthlib crate, and given that the crate is currently unmaintained, we're removing the CAL provider from the all-providers list and recommending it not to be included when packaging the Parsec service v1.0.0.

Once the project is placed under maintenance again, the provider can be added back and integrated in future builds of the service for distros. This should include not just the Cargo.toml change itself, but also enabling all the related e2e all-providers tests.

ionut-arm

ionut-arm

documentation
5

Posted as a comment by Matt in #570.

I know we originally made the provider name globally optional so that existing configs would not fail with new versions of Parsec. Would it be better for it to be optional for OnDisk KIM implementations (to ensure config stability), and required for SQLite KIM configs? This way it forces the user to edit the config and set the provider names with their "preferred" naming scheme; preventing the (probably common) case of a user changing from the OnDisk to SQLite KIM without reading any of the provider naming warnings (quoted below).

In my mind, by going from OnDisk -> SQLite the user is "opting-in" to a new feature-set and its requirements. The only concern from the stability requirements set out is New options should be optional. I would argue that, transitively, provider name in this case is optional as the manager_type="OnDisk" would have to be mutated to manager_type="SQLite" in order for provider name to become a required field.

Parsec Config Stability:

Old configuration files should still work with future stable Parsec versions, with the same default for optional options.

Configuration options should not disappear in future stable Parsec versions. Configuration defaults should remain the same. New options should be optional.

Current provider name warnings:

⚠ WARNING: Provider name cannot change. ⚠ WARNING: Choose a suitable naming scheme for your providers now. ⚠ WARNING: Provider name defaults to "mbed-crypto-provider" if not provided, you will not be able to change the provider's name from this if you decide to use the default. ⚠ WARNING: Changing provider name after use will lead to loss of existing keys.

On the note of these warnings. WARNING: Provider name cannot change. would probably read nicer as WARNING: Provider name should not change once set.. And maybe loss of existing keys to LOSS OF EXISTING KEYS to really drive the point home and draw the attention of skim readers.

Originally posted by @MattDavis00 in https://github.com/parallaxsecond/parsec/pull/570#discussion_r780397295

ionut-arm

ionut-arm

enhancement
0

As part of the key persistence tests meant to verify that old mappings created by the on-disk KIM are still valid under a current built of the Parsec service, we create keys for different providers using the on-disk KIM using this script and copying them across when actually running the CI. The CI then runs a number of checks for the providers that have support for such keys, to verify that the correct keys are still visible and usable.

One issue is that the Trusted Service provider is not included in this testing. The main reason was the impossibility of running both the Mbed Crypto provider and the TS provider in parallel in the script linked above (see an explanation here). However, a solution could be that we clear out the Mbed Crypto keys (*.psa_its), restart the system with only the TS provider enabled, generate the keys and copy across the mappings and the key files (again, *.psa_its). Since the namespace of the keys would collide with Mbed Crypto, they can be kept in a separate folder for when the TS tests occur.

ionut-arm

ionut-arm

code health
0

Following a discussion in a community meeting, it was agreed to align git dependencies between the Parsec crates to keep them pointed to the tip of the main branch. The proposed way to test this is to run periodic tests that force the use of whatever commit forms the tip of the branch and check that everything still compiles correctly.

ionut-arm

ionut-arm

question
0

An interesting point that surfaced in a Slack conversation on key attestation using ActivateCredential was that TPM Storage Keys (which are required as "attesting keys" for the ActivateCredential command) could potentially be used for other purposes as well by Parsec clients. Thus, if we go ahead with the suggested idea of adding a generic operation that will allow clients to, in this case, generate a Storage Key, we could add more parameters and/or options allowing the Storage Keys to be used in other ways, not just for attestation. An example use-case would be to allow clients to control under which storage keys their "normal"/generic keys are stored.

Another option would make the service generate a new Storage Key for each client in the system, so as to enforce the namespacing of keys in a more strict way.

This issue covers the investigation phase, to determine what other uses we could find, how easy they'd be to implement and so on.

MattDavis00

MattDavis00

enhancement
0

Currently the process of setting up a development environment on Ubuntu is to follow the steps within the Dockerfile here. This is a labor intensive task as not all commands Dockerfile -> Ubuntu translate one to one; for example, setting environment variables or changing the working directory. It would be good to have a shell script (or equivalent) to setup a Parsec environment given a list of providers you wish to use. This script would help lower the barrier for entry for contributors. This script can then be consumed by the docker image so there is no duplication of installation steps, almost all installation logic being defined within the shell script.

The script should implement everything included within the Dockerfile, and then the Dockerfile should be refactored to use this script instead.

For example something like:

Minutes discussing this issue:

  • Set up your dev env -> go through the Dockerfile to follow the commands. Need to be manual process because Docker specific. Shell script or something equivalent to set up everything.
  • Specific parameters for what you want provider to set up.
  • Lowering the entry barrier to contributors.
  • That script can be used in the Docker image to make sure it stays in sync.
  • Easier for new contributors than following other projects’ documentation.
ionut-arm

ionut-arm

enhancement
0

Testing for Key Info Manager functionality currently happens at two levels - unit tests for each individual KIM, and E2E tests for providers using the KIMs. However, a glue layer - called the KIM Client - exists between them, allowing the providers to interface with the KIM in a thread-safe way. The KIM Client also abstracts away the lower-level details of the KIM interface. This level is not directly tested in any way, but could benefit from some testing similar to that of the KIMs.

MattDavis00

MattDavis00

medium
1

Once the first release of the SQLiteKeyInfoManager has been made, we should have some tests to ensure that the KIM matches our stability requirements.

This can be similar to the testing performed here:

  1. Generate keys with old version of Parsec
  2. Test they are still valid and functional with the new version

In essence; this testing should ensure that a SQLiteKIM database, created with the first release of the SQLiteKIM, is still valid and functional in every future release of Parsec.

MattDavis00

MattDavis00

enhancement
1

Design the OnDisk->SQLite KIM migration script.

This script could have a config file for setting required fields such as the authenticator_id & provider_name. provider_uuid, key_name & application_name can be inferred from the values held within the OnDisk KIM.

Design considerations:

  • Within the OnDisk KIM it is possible to create two keys with the same name on different providers. The namespace for the keys held in the SQLiteKIM does not support this, keys are not separated by provider type. For example My Key 🔑 can exist within an MbedCrypto and TrustedServices provider at the same time, for the same client; this is not the case for the SQLiteKeyInfoManager. Some method for dealing with duplicate key names should be thought of. This could be an explicit mapping from old to new like Figure. 1.
  • The original data held within the OnDisk key info manager should not be altered. This data can serve as a backup if the migration fails.
  • We should think about how much data should be inferred/defaulted from the original OnDisk mappings. For example, provider_uuid can be inferred from the provider_id of the original KeyTriple. Likewise, application_name can be inferred from the original application name, an authenticator_id just needs appending. Could the authenticator_id be inferred from the new Parsec config.toml if there is only one? Could the provider_name be inferred from the config.toml if there is only one provider of each type?

Figure. 1

MattDavis00

MattDavis00

enhancement
0

Implement a migration script so that Parsec administrators can migrate their key mappings from the OnDiskKeyInfoManager to the SQLiteKeyInfoManager. Implementation should be based on the design agreed upon in the #518 discussion.

Steps

  • #518
hug-dev

hug-dev

help wanted
4

Parsec, and more specifically the Parsec Rust client, would be a good candidate for an Ockam Vault implementation. See this discussion for context.

This issue is about investigating what needs to be done to make it happen.

A Vault structure that uses the parsec-client dependency would have to be created and that structure would have to implement the ockam_vault_core traits.

Let's review them one per one (for the 0.20.0 version).

AsymmetricVault

ec_diffie_hellman: this seems to be the psa_raw_key_agreement function with the Ecdh algorithm. However, if the output Secret is meant to be used as key material stored securely, this is not enough (see this warning). Instead, we will have to chain a key agreement and a key derivation using the Parsec version of the PSA Crypto operation psa_key_derivation_key_agreement. This operation is a multi-part operation that has not yet been designed in Parsec.

Hasher

sha256 is available as psa_hash_compute with the Sha256 algorithm. Although since this operation should not be sensitive it could be implemented using a software library?

hkdf_sha256: The HKDF algorithm is part of the Parsec interface but as key derivation is a multi-step operation, it has not yet been designed in Parsec.

Note to myself: if hkdf_sha256 exists, does it mean that ec_diffie_hellman should only do the key agreement part but not the derivation? Does Ockam perform these two operations one after the other anyway?

KeyIdVault

Parsec already uses String to refer to keys stored in the various crypto backends so those methods should be trivial to implement.

SecretVault

All of those key management methods are already available in Parsec. Respectively:

  • psa_generate_key
  • psa_import_key
  • psa_export_key
  • key_attributes
  • psa_export_public_key
  • psa_destroy_key

The SecretAttributes look close enough to the Attributes with the following details:

  • Parsec only support persistent keys
  • the length of Parsec keys is in bits

For key types:

  • SecretType::Buffer should map to Type:RawData
  • SecretType::Aes should map to Type::Aes
  • SecretType::Curve25519 should map to Type::EccKeyPair or Type::EccPublicKey (I guess depending on the context) with the family EccFamily::Montgomery. For the Curve25519, the bits field should be 255. See this.
  • SecretType::P256 should be the same as above but with the ECC family set to EccFamily::SecpR1 and bits to 256. To double-check between SecpR1 and SecpK1.
  • SecretType::Bls: if this refer to that, I am not sure this is defined in the PSA Crypto API and hence we could not use it :(

Signer

sign should map to psa_sign_message. If we use a software implementation to hash the data before signing it, psa_sign_hash should be enough. I guess the algorithm to use could be deduced from the key type. Looks like it is going to be ECDSA in all cases? The input data and signature format should be checked: what hash needs to be used for data (or is it already hashed with something?). The format returned in Signature might not be the one we use in Parsec.

SymmetricVault

aead_aes_gcm_encrypt and _decrypt should be covered with psa_aead_encrypt and _decrypt. The algorithm to use should be Aes::Gcm.

Verifier

Similar to Signer with psa_verify_message.

wiktor-k

wiktor-k

bug
2

When importing private RSA keys Parsec uses a method that will make the keys unusable after a power cycle.

The import method uses load_external_rsa of TransientKeyContext.

The tss_esapi's TransientKeyContext.html::load_external_rsa uses the LoadExternal TPM function and saves the loaded keys in the Null hierarchy. Quoting the spec:

External objects are Temporary Objects. The saved external object contexts shall be invalidated at the next TPM Reset.

And the book:

Ephemeral keys are keys that are erased at reboot. An entire hierarchy, primary keys, storage keys, and leaf keys can be constructed in the NULL hierarchy. On reboot, as the seed changes, the entire key hierarchy is cryptographically erased. That is, the wrapped keys may exist on disk, but they can't be loaded.

The issue was observed by @ionut-arm on Slack. I'm just recording the problem so it's easier to track.

As far as I've seen it GnuPG uses TPM2_Import for moving private keys to TPM but that one requires a primary key to attach imported key to. (It's not currently implemented by tss-esapi crate but is on my radar in September).

Cc: @hug-dev

hug-dev

hug-dev

good first issue
0

Parsec currently allows having multiple KIM of the same type, by assigning them different name and using them in the providers configuration.

This issue is about adding configuration tests for a case where there are multiple KIM of the same type with at least two providers using them all.

hug-dev

hug-dev

good first issue
1

The name field of the key_manager section of the configuration is currently required:

That name is used for each provider to select it. In some conditions, if there is only one for example, that name could be made optional and all providers would use it directly. The name field could only be required when there is more than one KIM of the same type.

ionut-arm

ionut-arm

bug
0

I've tried running the all workflow in the ci.sh script and after an initial failure, trying to rerun resulted in errors related to the spire-server being unable to start, e.g.:

Also, the spire-server and a bunch of spire-clients were still running. Some cleanup steps should be introduced to allow rerunning the script.

Versions

Find the latest versions by id

1.0.0 - Mar 31, 2022

Main features delivered

  • Added a new Key Info Manager - the SQLite KIM - which will serve as the default KIM from now on.
  • Added and implemented a new operation, CanDoCrypto, which allows clients to verify the capabilities of the various backends before performing any actual cryptographic operations.
  • Added and implemented two operations, AttestKey and PrepareKeyAttestation, in the TPM provider, backed by TPM2_ActivateCredential.
  • Added support for importing ECC public keys in the TPM provider.

For a more comprehensive view of the release see the changelog below.

Changelog

1.0.0 (2022-03-21)

1.0.0-rc3 (2022-03-21)

Full Changelog

Fixed bugs:

  • Cargo audit failing #544

Merged pull requests:

1.0.0-rc2 (2022-03-02)

Full Changelog

Implemented enhancements:

Closed issues:

  • Update the Parsec Book to include SQLiteKeyInfoManager #532

1.0.0-rc1 (2022-02-16)

Full Changelog

Implemented enhancements:

  • parsec.service hardening #569
  • Implement CryptoCanDo for the Trusted Services and Mbed Crypto providers #543
  • Implement CryptoCanDo for TPM provider #542
  • Refactor the PKCS11 CryptoCanDo implementation #541
  • Implement ActivateCredential key attestation #539
  • Making the SQLiteKIM the default #531
  • Create a new KeyInfoManager based on SQLite #424
  • Add support for other cryptographic services in the Trusted Service provider #341
  • Add system emulation tests for TS provider #304
  • Add support for importing ECC public key in the TPM provider #170
  • Add asymmetric encryption to TS provider #580 (ionut-arm)
  • Change dependency revision for TSS crate #579 (ionut-arm)
  • Add systemd hardening options #572 (ionut-arm)
  • Make SQLite KIM default #570 (ionut-arm)
  • Feature sqlite kim #566 (ionut-arm)
  • Add error handling to ActivateCredential #562 (ionut-arm)
  • Add ActivateCredential tests and fixes #560 (ionut-arm)
  • Activate credential #558 (ionut-arm)
  • Expand support for importing public keys for TPM #540 (ionut-arm)
  • [CryptoAuthLib provider] PsaAeadEncrypt and PsaAeadDecrypt implemented #536 (TomaszPawelecGL)

Fixed bugs:

  • Disable test from old E2E suite #574
  • Errors in validating ECC key bits in PKCS11 provider #545
  • UnixDomainSocket connection returns error from server #528
  • Fuzz Testing & Nightly Cargo udeps are failing due to prost-derive #514
  • TPM Provider does not persist generated keys accross reboot #504
  • Issue with PKCS11 backend with Nitrokey HSM #380
  • Skip flakey test #577 (ionut-arm)
  • Fix codecov build #573 (ionut-arm)
  • Fix handling of bits in PKCS11 imports #546 (ionut-arm)

Closed issues:

  • Align with stable TSS crate #567
  • Stable 0.8.1 release depends on tss-esapi alpha #527
  • Create E2E tests for SQLite KIM #516
  • Switch to dynamic key names in tests #453
  • Add capabilities discovery operations #426

Merged pull requests:

  • Update Changelog and service version no. #583 (ionut-arm)
  • Bump bindgen dependency version #582 (ionut-arm)
  • Bump SQLite dependency #581 (ionut-arm)
  • [CryptoAuthLib provider] PsaRawKeyAgreement operation implementation #578 (akazimierskigl)
  • Implement can-do-crypto for TS and mbed-crypto providers #565 (anta5010)
  • Add error message if submodule not initialised #564 (ionut-arm)
  • [CryptoAuthLib provider] PsaCipherEncrypt and PsaCipherDecrypt implementation #563 (akazimierskigl)
  • Add clippy and fmt checkt to e2e_tests #561 (ionut-arm)
  • Re-factor e2e tests to use common key attributes functions #556 (anta5010)
  • Merge can-do-crypto branch into main #555 (anta5010)
  • Merge main branch changes into can-do crypto #554 (anta5010)
  • Jn9e9/issue453 #552 (jn9e9)
  • e2e CanDoCrypto tests for Hashes, ECC curves and Crypto algorithms #551 (anta5010)
  • Implement CanDoCrypto trait and use it for PKCS11 and TPM providers #550 (anta5010)
  • Use ec_params for can-do-crypto checks instead of hard-coded values #549 (anta5010)
  • Small refactor of PKCS11 CryptoCanDo #548 (anta5010)
  • Merge origin/main into can-do-crypto #547 (anta5010)
  • Increase the MSRV to 1.53.0 #535 (hug-dev)
  • Update the CHANGELOG file with 0.8.1 #533 (hug-dev)
  • Added the CanDoCrypto operation as well as fixing some of the other test scripts. #522 (Kakemone)

0.8.1 - Sep 27, 2021

Main features delivered

  • ECC keys are now supported in the PKCS11 provider
  • a SPIFFE based authenticator is now available
  • New CryptoAuthLib provider operation support: generate/import/export keys, sign/verify
  • The TPM provider can be set as optional depending on platform availability
  • The slot_number field is now optional
  • all-providers now contains the Trusted Service provider
  • The TPM provider has been updated to store keys in a different format, with migration capability from the previous format.

See the changelog below to see all differences with previous release.

Changelog

0.8.1 (2021-09-17)

Full Changelog

Implemented enhancements:

  • Add Unit Tests to SQLiteKeyInfoManager #510
  • Change KeyTriple to Include Auth ID, Provider Name & Provider UUID #488
  • Update provider to use new version fo TransKeyCtx #515 (ionut-arm)

Fixed bugs:

  • Decide and implement a new serialization format for KeyInfo #509
  • Memory leak in TS context #501
  • Disable broken workflows #525 (ionut-arm)

Closed issues:

  • Make a Parsec Ockam Vault: investigation issue #506
  • Add Basic SQLiteKeyInfoManager Storage/Retrieval Functionality #503
  • Add config tests for multiple provider names #496

Merged pull requests:

0.8.0 (2021-08-05)

Full Changelog

Implemented enhancements:

  • Add Provider Name Config Option #487
  • Add PKCS11 provider export-attributes switch #462
  • Refactor the all-providers workflow #455
  • Adjust linking for TS provider #427
  • Allow providers to be optional or conditional depending on platform feature availability #401
  • Add cross-compilation tests for the TPM provider #382
  • Make the slot_number field optional #375
  • Design workflow and associated APIs for key attestation in Parsec #370
  • Implement error handling for TS caller errors #332
  • Add release-build tests to CI #163
  • Add the possibility of changing key store location of Mbed Crypto provider #53
  • Add TS provider to all-providers #482 (ionut-arm)
  • Adjust TS provider linking #474 (ionut-arm)
  • Add cargo-audit config #473 (ionut-arm)
  • Update dependency on Trusted Services #467 (ionut-arm)
  • Add import and export support for ECC for PKCS11 #452 (ionut-arm)
  • Add a SPIFFE based authenticator #449 (hug-dev)
  • Add ECC functionality to PKCS11 prov #446 (ionut-arm)
  • Enable coverage testing for TS provider #434 (ionut-arm)
  • Create SECURITY.md #414 (ionut-arm)
  • Add TPM provider cross-compilation #403 (ionut-arm)
  • Added Option<Slot> to PKCS 11 Provider constructor #402 (Sven-bg)

Fixed bugs:

Security fixes:

  • Resurrect fuzz testing framework #422
  • Set up Github security policy #398
  • Investigate testing of Cryptoauthlib provider #315
  • rust-spiffe: make sure that the claims returned by the validation operation are as expected #290
  • rust-spiffe: provide a local validation of the JWT-SVID #289
  • Revive the fuzz testing framework #429 (ionut-arm)

Closed issues:

  • NXP PKCS#11 Parsec integration testing. #456
  • Split the build tests on a different CI workflow #447
  • Support ECC signing keys in the PKCS#11 provider #421
  • Stability: Communication with backends #412
  • Adopt CII Best Practices Badge from the LF #411
  • Unable to build parsec 0.7.2 with rust 1.43.1. Parsec 0.6.0 builds fine. #409
  • Stability: Build toolchain #408
  • Stability: Environment variables #405
  • Stability: Dynamic libraries dependencies #397
  • Stability: systemd communication #396
  • Stability: OS signals #395
  • Stability: Persistent state (key mappings) #394
  • Stability: Configuration file #393
  • Stability: CLI invocation #392
  • Stability: Authenticators #391
  • Stability: Communication with clients (listeners endpoint) #390
  • Stability: Communication with clients (operation contracts) #389
  • Stability: Communication with clients (requests/responses) #388
  • Setup environment stability test #386
  • Archive for 0.7.0 contains .cargo/ folder #377
  • Add more Fixed Common header tests #351

Merged pull requests:

0.7.2 (2021-03-25)

Full Changelog

Merged pull requests:

0.7.1 (2021-03-25)

Full Changelog

Closed issues:

  • Investigate calculating test coverage #342

Merged pull requests:

0.7.0 - Mar 23, 2021

Changelog

0.7.0 (2021-03-23)

Full Changelog

Main features and bugfixes delivered

  • Added support for admin clients in the service. Admins can perform two operations forbidden for other clients: ListClients (returns a list of clients with active data available in at least one provider), and DeleteClient (which removes all data stored by the service for a given client).
  • Updated our PKCS11 backend to use an improved, higher-level crate (cryptoki) that offers a safer interface.
  • Two new providers were added, one for ATECCx08 devices via CryptoAuthLib, and one for Trusted Services running in a Trusted Execution Environment. Both are under development and thus not ready for production deployments.
  • Fixed a bug where all keys reported by ListKeys were shown as MbedCryptoProvider keys.

Implemented enhancements:

  • Stop the duplication of key ID conversions #331
  • Add key management operations support #267
  • Enable TS context initialization #266
  • Create the Trusted Service bindings #265
  • Improve import key support in TPM provider #251
  • Investigate and define the work required for SPIFFE-based client identity management #232
  • Make existence of key info consistent with existence of key #149
  • Extract Docker images into own repo #124
  • Add version structures for better handling of versions #43
  • Rearrange modules for a more structured feel #32
  • Change CI to use published Docker image #357 (ionut-arm)
  • Improve coverage script #348 (ionut-arm)
  • Add coverage checking in nightly run #347 (ionut-arm)
  • Trusted service provider #330 (ionut-arm)
  • Add admin configuration #316 (ionut-arm)
  • Add new parsec provider using ATECCx08 cryptochip via CryptoAuthentication Library #303 (RobertDrazkowskiGL)
  • Improve error handling in builder #298 (ionut-arm)
  • Add Changelog file (#278) #280 (ionut-arm)
  • Remove PKCS11 single thread lock (#264) #277 (ionut-arm)

Fixed bugs:

  • Move the spiffe related features in its own branch #327
  • Resolve default implementation issue for list\_keys in Provide #312
  • ListKeys should only be callable on the Core provider #310
  • Service should not start if some components weren't built successfully #297
  • No changelog for the releases #278
  • PKCS11 multi-threading #264
  • Fix ImportKey to allow importing private key #126
  • PKCS 11 provider stress tests sometimes fail #116
  • Update docker registry for TPM2 images #356 (ionut-arm)
  • Run the Codecov script outside container #353 (ionut-arm)
  • Fix code coverage docker command #352 (ionut-arm)
  • Remove the spiffe-based authenticator #328 (hug-dev)

Security fixes:

  • Add a test for admin operations #309
  • Implement admin logic #308
  • Investigate admin role and admin-level operations #292
  • Add failure-counter mechanism #176

Closed issues:

  • Implement ListClients and DeleteClient in the core provider #311
  • Correct lint issues found after the toolchain upgrade to version 1.49.0 #305
  • Investigate cross-compilation to Linux on Aarch64 #300
  • Investigate adding ListClients and DeleteClient operations #293
  • Consume the new, safer Rust PKCS#11 interface into Parsec when it is available #272
  • Add a SPIFFE JWT-SVID multitenancy test #269
  • Add a JWT-SVID Authenticator #268
  • Investigate and define the work required for compatibility with Arm Firmware Framework for Armv8-A (FF-A) #247

Merged pull requests:

0.6.0 - Oct 30, 2020

Changelog

0.6.0 (2020-10-20)

Full Changelog

Main features delivered

  • Authentication support for Unix Peer Credentials (for Domain Sockets); authenticators are now configurable at runtime using config.toml
  • Added support for an operation (ListKeys) to list all keys belonging to a client
  • Removed filesystem checks (ownership/permissions) as we can now more safely rely on valid setup by the admin

Implemented enhancements:

  • Add multitenancy testing infrastructure 👩‍🔧 #245
  • Delete "Provider" suffix out of provider names #134
  • Improve error message on service startup #260 (ionut-arm)

Fixed bugs:

Closed issues:

  • Add authenticator configuration #270
  • Assemble a PR checklist for code reviewers #258
  • Adjust README disclaimer wording #231

Merged pull requests:

0.5.0 - Oct 30, 2020

Changelog

0.5.0 (2020-10-02)

Full Changelog

Main features delivered

  • Moved the Parsec service assets to locations in the filesystem where they would match the FHS spec
  • Added memory cleanup for sensitive buffers - before the memory is released, the contents are scrubbed away

Implemented enhancements:

  • Creating a build-time configuration file #256
  • Merge integration tests in E2E test suite #228
  • Support dbus-parsec with NXP secureobj library #223
  • Verify which dependencies can/should be updated #158
  • Add more test cases #151
  • Test Parsec installation as a systemd daemon #49
  • Improve E2E testing #253 (ionut-arm)
  • Upgrade and clean dependencies #246 (hug-dev)
  • Import private key support for TPM provider #243 (joechrisellis)
  • Allow software operations in PKCS11 provider #241 (ionut-arm)
  • Improve key metadata handling #240 (ionut-arm)
  • Add support for psa\_generate\_random operation for MbedCrypto provider #208 (joechrisellis)

Fixed bugs:

Security fixes:

Closed issues:

  • Implement ListAuthenticators #216
  • Better error message when file not found #210
  • Implement an authenticator based on the domain socket peer credential #200

Merged pull requests:

Information - Updated Jun 22, 2022

Stars: 337
Forks: 48
Issues: 61

Rocket is an async web framework for Rust with a focus on usability, security,

Visiting localhost:8000/hello/John/58, for example, will trigger the hello

Rocket is an async web framework for Rust with a focus on usability, security,

macOS/iOS Security framework for Rust

MIT license (LICENSE-MIT or

macOS/iOS Security framework for Rust

libdiffuzz: security-oriented alternative to Memory Sanitizer

This is a drop-in replacement for OS memory allocator that can be used to detect uses of uninitialized memory

libdiffuzz: security-oriented alternative to Memory Sanitizer

Transparent endpoint security

Block and detect advanced attacks

Transparent endpoint security

A WIP Rust implementation of Messaging Layer Security based on draft 9+

Messaging Layer Security based on draft 9+

A WIP Rust implementation of Messaging Layer Security based on draft 9+

Rust Language Security

execrices: RUSTSEC-2021-0001

Rust Language Security

No security audit has been performed

There are currently 3 interesting things

No security audit has been performed

security-keys-rust

Many thanks to the authors of the openpgp-card Rust crate

security-keys-rust

Owlyshield open source security platform

An OSS security platform written in rust with security threat detection

Owlyshield open source security platform

No security audit has been performed

There are currently 3 interesting things

No security audit has been performed
Facebook Instagram Twitter GitHub Dribbble
Privacy