Attestation libraries

[gmandyam]

Add attestation service. Initial cut.

[rusty1968]

We don't need the exact = pin here. The committed Cargo.lock already resolves cortex-m-rt (and cortex-m-rt-macros) to exactly 0.7.5 with a checksum, so every build that respects the lockfile is already reproducible — the = on the requirement doesn't add any determinism on top of that.

[gmandyam]

Changed accordingly. Exact pin removed.

[rusty1968]

Quick note on Cargo.toml files: this is a Bazel project, so the only manifest we actually need is Cargo.toml — that's what drives crate_universe / external crate resolution for Bazel. All the per-crate Cargo.toml files scattered under services (attest, spdm, mctp, etc.) aren't used to build or test anything; the real target and dependency definitions live in each crate's BUILD.bazel.

[rusty1968]

As written, both attest crates are std-based and heap-allocating. Please make sure all crates are no_std.

[rusty1968]

Suggested change

	#![no_std]
	#![forbid(unsafe_code)]

[gmandyam]

Added. See lib.rs files.

[rusty1968]

One thing I noticed: dice_identity.rs and measurements.rs are each basically a whole module wrapping a single pub fn that's only ~1-3 lines — collect is a loop + extend, cert_chain is one call + a length check, and alias_cert is a straight pass-through (and dead). It's a bit of a "one file per function" thing, where the module boundary costs more than the logic it's hiding. These would be better as private helpers/methods behind HwAttestProducer.

[rusty1968]

openprot-secure-coding — violation

zeroize is added as a dependency (producer/Cargo.toml:19, producer/BUILD.bazel:16) and
the README (producer/README.md:81) documents it as "Zero-on-drop for intermediate key
material and sensitive buffers" — but it's never imported or called anywhere in the source.
Dead dependency, and the security claim in the README is currently false.

[gmandyam]

As written, both attest crates are std-based and heap-allocating. Please make sure all crates are no_std.

Moved to heapless.

[gmandyam]

openprot-secure-coding — violation

zeroize is added as a dependency (producer/Cargo.toml:19, producer/BUILD.bazel:16) and the README (producer/README.md:81) documents it as "Zero-on-drop for intermediate key material and sensitive buffers" — but it's never imported or called anywhere in the source. Dead dependency, and the security claim in the README is currently false.

Removed and README updated.

[chrysh]

@gmandyam Are the tests already running in the CI when you push to the PR?

[chrysh]

Is this trait always going to be calling into caliptra? Otherwise, should we choose a more generic name? E.g. rot_measurements?

[gmandyam]

This trait leverages Caliptra. Making the name space generic is not going to change the dependencies on Caliptra.

[chrysh]

Can we guarantee that in 5 years caliptra will still be our only measurement source? If yes, then keep the name. If we might have a different measurement device, the name should be more generic.

Note the api crate itself already has no Caliptra dependency (BUILD deps are heapless and thiserror; the mailbox code is in the producer). So the name is the only Caliptra thing in the seam, and renaming it costs nothing.

[gmandyam]

Can we guarantee that in 5 years caliptra will still be our only measurement source? If yes, then keep the name. If we might have a different measurement device, the name should be more generic.

Note the api crate itself already has no Caliptra dependency (BUILD deps are heapless and thiserror; the mailbox code is in the producer). So the name is the only Caliptra thing in the seam, and renaming it costs nothing.

OpenPRoT is intended to be an OCP standard (see https://www.amd.com/en/blogs/2025/openprot--building-a-secure-and-transparent-foundation-for-platf.html). OCP created Caliptra and still refers normatively to Caliptra in relevant specifications (e.g. see https://opencomputeproject.github.io/Security/device-identity-provisioning/HEAD/). The RoTs are not interchangeable from that perspective. At very least any RoT must support TCG DICE and be OCP SAFE certifiable (https://github.com/opencomputeproject/OCP-Security-SAFE/tree/main/Reports/CHIPS_Alliance).

[chrysh]

The SAFE and DICE requirement is the part that argues for the generic name. "Any
RoT must support TCG DICE and be OCP SAFE certifiable" describes a class of
devices, so the trait method should be named after the role in that class, not
after one product in it. A normative reference to Caliptra says Caliptra is a
conforming RoT, not that a portable trait method has to carry its name.

This tree already ships more than one RoT. target/earlgrey is OpenTitan Earl
Grey, target/veer is the Caliptra emulator, and both run in ./pw ci. On the
Earl Grey port the firmware measurements come from OpenTitan, not from a
Caliptra mailbox, so HwSigner::caliptra_measurements is already the wrong name
for one of the two platforms we build today.

To be clear about scope, I am not asking to scrub Caliptra from the crate.
MeasurementAuthority::Caliptra should stay: it tells the verifier the digest
came from Caliptra rather than from a platform provider asserting about itself,
which is exactly the distinction that decides how much the digest is worth.
AttestError::Caliptra for mailbox errors is fine too. Those name a real thing.
The trait method names a role, and that is the only line I want changed:

fn caliptra_measurements(...)  ->  fn rot_measurements(...)

One rename plus its call sites, cheap now and awkward once anyone outside this
repo implements HwSigner.

One small ask on process: could you leave threads open until whoever raised
them has had a look? I resolve mine as soon as I have checked the fix, so
nothing sits around, and it keeps the open threads as an accurate list of what
is still being discussed.

[rusty1968]

Agree with Chrsina on the naming - +1

The SAFE and DICE requirement is the part that argues for the generic name. "Any RoT must support TCG DICE and be OCP SAFE certifiable" describes a class of devices, so the trait method should be named after the role in that class, not after one product in it. A normative reference to Caliptra says Caliptra is a conforming RoT, not that a portable trait method has to carry its name.

This tree already ships more than one RoT. target/earlgrey is OpenTitan Earl Grey, target/veer is the Caliptra emulator, and both run in ./pw ci. On the Earl Grey port the firmware measurements come from OpenTitan, not from a Caliptra mailbox, so HwSigner::caliptra_measurements is already the wrong name for one of the two platforms we build today.

To be clear about scope, I am not asking to scrub Caliptra from the crate. MeasurementAuthority::Caliptra should stay: it tells the verifier the digest came from Caliptra rather than from a platform provider asserting about itself, which is exactly the distinction that decides how much the digest is worth. AttestError::Caliptra for mailbox errors is fine too. Those name a real thing. The trait method names a role, and that is the only line I want changed:

fn caliptra_measurements(...)  ->  fn rot_measurements(...)

One rename plus its call sites, cheap now and awkward once anyone outside this repo implements HwSigner.

One small ask on process: could you leave threads open until whoever raised them has had a look? I resolve mine as soon as I have checked the fix, so nothing sits around, and it keeps the open threads as an accurate list of what is still being discussed.

I agree the naming should reflect the vocabulary of the domain. There was another instance where Caliptra was part of the name of the type and we got rid of that.

[gmandyam]

You both are missing the main point: the checks in the code (e.g. DICE identity) are specific to Caliptra. That is by design. Changing the function naming is syntactic sugar - nothing more. OpenTitan will fail as a DICE identity provider because it follows the OpenDICE standard. If an IHV wants to use a different RoT then that is up to them to customize the code base.

I will genericize the names but that won't affect the checks in the code.

[chrysh]

If it is caliptra specific, then it should not be in something called services/attest/api/src/types.rs. A programmer that looks at this directory expects something generic. Can you make sure that any code that is
caliptra specific resides in a directory or filename that contains caliptra, e.g. services/attest/implementations/caliptra.rs? Any code that can also be reused for other attestation devices can be in the types.rs.

If we don't design our software this genric way, we will accumulate technical debt that we don't want for the future, which will make it harder to extend the software.

Does that make sense to you?

[gmandyam]

Can you make sure that any code that is caliptra specific resides in a directory or filename that contains caliptra, e.g. services/attest/implementations/caliptra.rs?

Yes - this suggestion makes sense.

If we don't design our software this genric way, we will accumulate technical debt that we don't want for the future, which will make it harder to extend the software.

Agree.

[gmandyam]

Change has been made by adding caliptra.rs. Please verify.

[chrysh]

why do we use different conventions here? out.push vs p.measurements(out)?

Furthermore, "append" is a convention, not a contract. Nothing in the
trait doc at types.rs:77-81 says a provider must only append. A provider calling
out.clear() silently drops the RoT's own measurements, and the token still signs and verifies fine. That is a platform component erasing the root of trust's measurements from an attestation token.

Possible but maybe not the best fix in collect, but no extra buffer and no extra stack:

for p in providers {
let start = out.len();
p.measurements(out)?;
if out.len() < start {
return Err(AttestError::Provider("provider shrank the measurement list"));
}
}

plus one line on the trait: implementations append, they never remove or reorder existing entries.

[gmandyam]

why do we use different conventions here? out.push vs p.measurements(out)?

Agentic inefficiency. Change made.

Furthermore, "append" is a convention, not a contract. Nothing in the
trait doc at types.rs:77-81 says a provider must only append. A provider calling
out.clear() silently drops the RoT's own measurements, and the token still signs and verifies fine. That is a platform component erasing the root of trust's measurements from an attestation token.

This is a reasonable suggestion, but I won't incorporate it for now.

OCP-EAT ((https://opencomputeproject.github.io/Security/ietf-eat-profile/HEAD/) is a profile of the EAT specification (RFC 9711). I deliberately did not specify where profile compliance is enforced in RFC 9711 (https://www.rfc-editor.org/info/rfc9711/#section-6), so the enforcement point could be at the attester or verifier.

OCP-EAT requires certain mandatory claims including measurements. However, the front matter of OCP-EAT states the following regarding mandatory claims: "These claims are REQUIRED for all attestations and provide the minimum necessary information for verifier appraisal policies. The verifier can expect at a minimum these claims in a compliant attestation ...".

It is up to the remote verifier to evaluate attestation tokens and make appraisal decisions based on the received evidence (including the profile claim), and this involves more than just verifying the token signature ("silently drops the RoT's own measurements, and the token still signs and verifies fine"). If the provider attempts to remove measurements that are expected in the token, the verification will fail because expected measurement values are missing.

[gmandyam]

@gmandyam Are the tests already running in the CI when you push to the PR?

CI tests are always re-executed upon a new push (as far as I can tell). Is this not your experience?

[rusty1968]

@gmandyam remove the SKILLS from this PR. I created them for our internal use, it seems you added to your PR by accident.

[rusty1968]

Is the name of this service attest or verifier?

[gmandyam]

@rusty1968 @gmandyam Are we adding AI skills to the repo now?

Removed the skills.

[gmandyam]

@gmandyam remove the SKILLS from this PR. I created them for our internal use, it seems you added to your PR by accident.

Done.

[gmandyam]

Is the name of this service attest or verifier?

Attest. Verifier (local verifier) is part of the attestation service per design specification - see https://github.com/OpenPRoT/openprot/blob/main/docs/src/specification/services/attestation.md.

[chrysh]

features is Bazel's own attribute, not the rules_rust one. The Rust feature
never gets set, so #![cfg(feature = "test-support")] at
tests/producer_integration.rs:6 strips the whole file and the target compiles to
an empty crate. Bazel then reports it as PASSED with zero tests, locally and in
./pw ci, so all nine tests in there have never run.

Three changes to make them run. The attribute rename alone is not enough,
because SoftwareAttestProducer is itself behind the feature, so the test needs
a library built with it:

Suggested change

	rust_test(
	name = "attest_producer_unit_test",
	crate = ":attest_producer",
	features = ["test-support"],
	deps = [
	"//services/attest/api:attest_api",
	],
	)
	rust_test(
	name = "attest_producer_integration_test",
	srcs = ["tests/producer_integration.rs"],
	edition = "2021",
	features = ["test-support"],
	deps = [
	":attest_producer",
	"//services/attest/api:attest_api",
	"@rust_crates//:ciborium",
	],
	)
	rust_library(
	name = "attest_producer_test_support",
	srcs = glob(["src/**/*.rs"]),
	crate_features = ["test-support"],
	crate_name = "openprot_attest_producer",
	edition = "2021",
	deps = [
	"//services/attest/api:attest_api",
	"@rust_crates//:heapless",
	"@rust_crates//:minicbor",
	],
	)
	rust_test(
	name = "attest_producer_unit_test",
	crate = ":attest_producer",
	crate_features = ["test-support"],
	deps = [
	"//services/attest/api:attest_api",
	],
	)
	rust_test(
	name = "attest_producer_integration_test",
	srcs = ["tests/producer_integration.rs"],
	crate_features = ["test-support"],
	edition = "2021",
	deps = [
	":attest_producer_test_support",
	"//services/attest/api:attest_api",
	"@rust_crates//:ciborium",
	"@rust_crates//:heapless",
	],
	)

heapless is new in the test deps: it is used at producer_integration.rs:8 and
only shows up as an unresolved import once the file actually compiles.

With this on 73f549d the integration test runs 9 tests and all pass, the unit
test stays at 16. Checked with

bazel test //services/attest/producer:attest_producer_integration_test \
    --test_output=all --nocache_test_results

[chrysh]

Filed the CI side as #462: a rust_test whose sources are all stripped by cfg reports PASSED with zero tests, so this target was green from the day it was added.

[gmandyam]

Thank you for pointing this out. I will make the changes and verify the CI picks them up.

[chrysh]

Looking at the CI log, those tests don't show up:

sign_receives_cose_sig_structure_for_payload
generate_token_rejects_chain_with_fewer_than_two_certs
nonce_outside_rfc9711_length_range_is_rejected
dbgstat_ueid_oemid_and_sw_claims_match_config
seventeenth_measurement_overflows_at_add_provider
provider_clearing_out_cannot_produce_a_token

The second one is not dice_identity::tests::rejects_chain_with_fewer_than_two_certs,
which does run: that covers the helper, and nothing covers the generate_token
path, which never calls it.

[gmandyam]

Looking at the CI log, those tests don't show up:

sign_receives_cose_sig_structure_for_payload
generate_token_rejects_chain_with_fewer_than_two_certs
nonce_outside_rfc9711_length_range_is_rejected
dbgstat_ueid_oemid_and_sw_claims_match_config
seventeenth_measurement_overflows_at_add_provider
provider_clearing_out_cannot_produce_a_token

The second one is not dice_identity::tests::rejects_chain_with_fewer_than_two_certs, which does run: that covers the helper, and nothing covers the generate_token path, which never calls it.

Looks like the tests are showing up in the log now.