Duplicate and Conflicting Endorsement Entries in kvstore

[jeevan0920]

Hi Veraison Team,

I was testing the provisioning API by submitting endorsements from the PoC endorser for ARM CCA support. During this process, I observed a behaviour that may be problematic or unintended:

🔁 Submitting the same endorsement multiple times results in duplicate entries in the endorsement store database (kvstore).

---

🧪 Steps to Reproduce

These are the exact steps I followed to reproduce the issue:

✅ 1. Clone and build Veraison services

git clone https://github.com/veraison/services.git
cd services/deployments/docker
make
source env.bash

This builds the Docker images:

• veraison/keycloak
• veraison/vts
• veraison/provisioning
• veraison/verification
• veraison/management

Start all services:

veraison start
veraison status  # confirm all are running

Reference: [Veraison Docker deployment guide](https://github.com/veraison/services/tree/main/deployments/docker)

---

✅ 2. Clone and build the PoC endorser

git clone https://git.codelinaro.org/linaro/dcap/cca-demos/poc-endorser.git
cd poc-endorser
make

🔧 Modify endorse.sh:

-api_server=https://provisioning-service:8888/endorsement-provisioning/v1/submit
+api_server=https://provisioning-service:9443/endorsement-provisioning/v1/submit

🔧 Modify Makefile:

-endorse: ; docker run --network=host $(TAG)
+endorse: ; docker run --network=veraison-net $(TAG)

---

✅ 3. Submit endorsements

Submit the original endorsements:

make endorse  # 1st time
make endorse  # 2nd time (same data)

Then, modify the BL1 measurement value in the input, and submit again:

# BL1 measurement changed in input cbor file (generated using evcli)
make endorse  # 3rd time (conflicting value)

---

🧾 4. Query the endorsement store (VTS)

docker exec vts-service sqlite3 /opt/veraison/stores/vts/en-store.sql \
  "SELECT * FROM kvstore;" | grep rC27mzsskJvCzIG7wdFeL5V2byU9vP+Orhqo=

Example output:

ARM_CCA://0/f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAUFgAAAAAAAA=| { ... "measurement-value": "micfKpFr..." }
ARM_CCA://0/f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAUFgAAAAAAAA=| { ... "measurement-value": "micfKpFr..." }
ARM_CCA://0/f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAUFgAAAAAAAA=| { ... "measurement-value": "dhanus/..." }

As seen above:

• The same entry was stored twice for the same kv_key.
• A third, conflicting value with the same kv_key was also accepted.

---

❓ Open Questions

This raises some concerns and requests for clarification:

1. Is this behavior expected?

• Should the provisioning API deduplicate or overwrite endorsements for an existing key?
• Should it reject conflicting entries?

2. How does verification handle this?

• If multiple entries exist under the same key but with different measurement-value fields, how does the verifier choose which one to match against?
• Is there a coalescing strategy or precedence rule?

---

[setrofim]

1. Yes, this is expected behavior. It is possible to have multiple endorsement entries associated with the same attester ID (e.g. different instances can have different versions of the same component). Multiple entires under the same key are not confling, but complementing -- the endorsements associated with an attester ID are considered to be the union of all entries found in the store. (note: when entries are completely identical, there would be no point in storing all of them, but we currently do not have duplicate detection implemented, and it is not a hight priority, as it is not a problem in practice).
2. The verifier fetches all entries associated with an ID, and then tries to match the evidence to any of the entries recieved, so it doesn't matter if there duplicates among the fetched endorsements -- the evidence just has to match any of them, not exactly one.

[jeevan0920]

Thanks for the clarification, @setrofim.

I'd still like to raise a concern regarding the lack of duplicate detection. Allowing duplicate entries—even if identical—can lead to unnecessary bloat, especially in systems where endorsements may be submitted repeatedly due to automation errors or manual mistakes. Over time, this could impact storage efficiency and operational clarity, and in some cases, could even present a vulnerability surface if abuse is possible.

There are only negatives to allowing duplicates—no clear benefits. We’d be happy to contribute a patch to add basic deduplication logic if the team is open to it.

[setrofim]

There are only negatives to allowing duplicates—no clear benefits. We’d be happy to contribute a patch to add basic deduplication logic if the team is open to it.

The main issue with duplicate detection, is that the only way to do it with the current schema is get all existing values for a key from the store and then loop through them. This would need to be done for each new value being stored, so puts a non-trivial cost on each submission request.

Our plan is to eventually address this as part of a wider endorsement lifecycle management change. However, we do not currently have an ETA on that, so feel free to subit a pull with duplicate detection in the mean time.

[jeevan0920]

@setrofim Thanks for the clarification earlier — we’re currently exploring deduplication options.

---

While reviewing the ARM CCA evidence verification flow, I noticed a potential discrepancy (if I understand it correctly) between the described behavior and the actual logic in the code — specifically regarding how multiple endorsements with the same implementation ID are handled for platform software components.

---

🔍 Expected vs. Actual Behavior

Your earlier statement:

"Multiple entries under the same key are not conflicting, but complementing — the endorsements associated with an attester ID are considered to be the union of all entries found in the store... The verifier fetches all entries associated with an ID, and then tries to match the evidence to any of the entries received, so it doesn't matter if there are duplicates — the evidence just has to match any of them, not exactly one."

Observed implementation:
The function MatchSoftware in scheme/common/arm/handlers.go (lines 107–160) appears to implement AND-based logic, not the described OR-based matching.

---

📄 Code Reference

func MatchSoftware(scheme string, evidence psatoken.IClaims, endorsements []handler.Endorsement) bool {
    matched := false
    for _, endorsement := range endorsements {
        matched = true

        // ... matching logic ...

        if !(typeMatched && sigMatched && versionMatched) {
            matched = false
            break  // Critical: fails on first mismatch
        }
    }
    return matched
}

This logic returns true only if all endorsements match the evidence. A single mismatch results in overall verification failure.

[setrofim]

This is a known issue with the CCA scheme. The reason for this is that the fields identifying software components are optional in th evidence, so we cannot rely on them to match the relevant endorsements. Our solution at the moment is to assume that all endorsements are relevant.This means that at teh moment, it is not possible to have updates. We plan to address this as part of the previously mention wider endorsement lifecycle management changes.

[jeevan0920]

Thank you for the response and for explaining the current behavior in more detail.

"The verifier fetches all entries associated with an ID, and then tries to match the evidence to any of the entries received, so it doesn't matter if there are duplicates — the evidence just has to match any of them, not exactly one."

I wonder whether this holds true in practice, especially for platform software components in the ARM CCA scheme. Could this approach lead to the acceptance of evidence that unintentionally mixes versions, such as those resulting from partial updates?

Clarification Question: Are partial combinations of component measurements supported?

Consider a scenario where the platform consists of four components: A, B, C, and D. Initially, an endorsement is submitted for the full set:

• A: Hash_A1
• B: Hash_B1
• C: Hash_C1
• D: Hash_D1

Later, components A and C are independently updated — say, due to firmware changes or security patches — and a new endorsement is submitted reflecting the updated state:

• A: Hash_A2
• C: Hash_C2

Now, the endorsement store contains multiple valid hashes for A and C: both Hash_A1/A2 and Hash_C1/C2.

Suppose the verifier receives evidence with:

• A: Hash_A2
• B: Hash_B1
• C: Hash_C1
• D: Hash_D1

This measurement set reflects a hybrid state — part of the system is running the updated software, while other components remain unchanged. However, this exact combination was never endorsed as a known-good set.

Should such hybrid evidence be considered valid? Or should the verifier treat it as invalid or suspicious, since the specific combination does not correspond to a fully endorsed set of component measurements?

We’re trying to understand whether this behavior is intentional under ARM CCA assumptions.

[setrofim]

This is the intended behavoir of the current scheme implementation. Each SW component is verified individually that it is in a known good state. There is no concept of "known good combination" of components. If the compoments can be updated independently of each other, the potential number of such combinations would grow exponentially, which is why the compoments are verified individually.

We’re trying to understand whether this behavior is intentional under ARM CCA assumptions.

This is the assumption of the current verification scheme, not of Arm CCA, which does not specify exactly how the verfier must evaluate CCA evidence. It is possible to implement a different scheme, that does check for specific combinations. It is also possible to add a Rego policy on top of the existing scheme that would ensure that a particular combination of components is used.