Selective Disclosure: Encrypt the Claim, Keep the Relationship
In Petra, an access decision is not attached to an undifferentiated file. It is attached to a location in the SBOM tree: a claim about a particular artifact or dependency. That design answers the practical question at the center of this discussion: how can a producer let a vulnerability scanner read a version while withholding the same version from another audience, without destroying the relationship that gives the version meaning? Understanding the policy and key flow makes Petra’s idea of verifiability more concrete: different readers can receive different semantic views of one structured record.
A policy is a question about a path
The producer begins with a question about use. Which information does a recipient need to perform an authorized job, and which information should remain protected? In Petra, the answer is expressed as a combination of paths in the SBOM tree and access trees attached to those paths. A path identifies the kind of claim and the object it belongs to. The access tree describes the attributes a principal must possess before the corresponding field can be decrypted.
Those attributes are properties associated with a consumer or an approved service. They can describe a role, an organization, a location, an application, a certification, or a time window. An access rule can require several properties together or accept one of several alternatives. The important idea is that the key does not simply say “this person may open this file.” It carries attributes that can be tested against the policy protecting a particular claim.
Consider package foo, which includes dependency bar. The producer may regard the version of bar as sensitive because it reveals part of the product’s composition or helps an observer reason about a known weakness. At the same time, a vulnerability-scanning service may need that version to determine whether a relevant advisory applies. Petra can express a rule under which a scanner with the required authorization—such as an approved role or certification—can read dependency versions. A licensing consumer does not need that same field. The licensing task may require the package name and its license instead, so those claims can be placed under a different rule.
This is more precise than giving both consumers the same broad permission and asking them to ignore what they do not need. It is also more useful than removing the version from every copy. The producer can distribute one redacted tree whose nodes are governed by different policies. A consumer receives plaintext only for the claims their attributes authorize; the rest of the tree remains present but protected.
The distinction between a policy and a person matters here. Petra’s producer authors the policy, while the KMS authenticates a principal and issues a key containing the attributes that principal is allowed to use. The KMS does not decide that a licensing team is entitled to vulnerability data simply because it has authenticated successfully. Nor does a consumer get to add an attribute merely by claiming a different role. Authorization depends on the relationship between the issued attributes and the policy attached to the node.
A time condition adds another useful boundary. A key can carry a time-window attribute or an expiry condition, so authorization is not necessarily permanent. Petra’s design also allows delegated issuance for a subset of attributes. That could let one organization grant a narrower capability to a member without handing over the authority to issue every kind of key. These features do not remove the need for governance: the KMS must bind attributes correctly, and the producer must choose a policy that preserves enough information for the intended task.
The flow looks like this:
The diagram shows two different outcomes from the same distributed structure. The scanner and licensing consumer do not need separate, manually edited documents. They receive the same redacted tree and apply their own keys to it. If a policy is not satisfied, the node does not become a blank value or disappear; it remains encrypted. That behavior preserves the distinction between “this claim exists but I am not authorized to read it” and “this claim was never part of the record,” although a consumer may still need additional integrity evidence to check that distinction.
Why Petra encrypts keys, not every claim directly
The underlying primitive is Ciphertext-Policy Attribute-Based Encryption, or CP-ABE. The name describes the direction of control. In ordinary public-key encryption, a sender generally encrypts to a known recipient key. In CP-ABE, the ciphertext carries an access policy, while a consumer’s secret key carries attributes. The decryption operation succeeds only when the attributes satisfy the policy embedded with the protected data.
That arrangement fits a supply chain with many possible recipients. The producer does not need to create a separate conventional encryption key for every future scanner, auditor, or downstream organization. The producer describes the condition for access, and the KMS issues keys whose attributes represent the authority of each principal. A key for an approved vulnerability scanner can satisfy one policy; a key for a licensing service can satisfy another.
Petra does not use CP-ABE to encrypt the full payload of every tree node directly. Instead, it uses CP-ABE as a key-encapsulation mechanism. For each distinct access policy, the design creates a random AES key. That symmetric key encrypts the data in all nodes to which the policy applies. CP-ABE then protects the AES key under the policy. A consumer whose attributes satisfy the policy first obtains the corresponding symmetric key through the CP-ABE layer and can then decrypt the applicable node data.
This division of labor is a practical engineering choice. Symmetric encryption is efficient for the data itself. Attribute-based encryption supplies the fine-grained authorization rule. If the same policy applies to many fields, reusing the policy-level symmetric key avoids performing an expensive attribute-based payload operation for every field. The result is still node-selective from the consumer’s perspective: a key is useful only for the nodes associated with its policy.
The construction also gives policy complexity a visible cost. A simple audience rule may require fewer attributes and less policy material than a rule combining organization, role, approval status, tool identity, and time. More elaborate policies can enlarge the protected representation and increase processing work. The policy is therefore not a free label attached to data; it is part of the exchange state that must be generated, stored, evaluated, and maintained.
Petra’s choice preserves relationships because it does not encrypt the references connecting complex nodes to their children. A consumer can still see that a dependency belongs beneath an artifact and that several claims belong to that dependency. They may see the location of a protected version even when the version itself is unreadable. That visible structure supports search, composition, and later membership checks. It also means that the system is not hiding the entire dependency graph.
The remaining exposure is not accidental. An observer may be able to infer something from the structure of the tree or from the attributes named in an access policy. The paper notes that an access policy can reveal a field name indirectly through the attributes it allows, even while protecting the field value. A dependency node with an unusual number of children may also suggest what kind of complex object it represents. These clues are the price of keeping the record usable for parties that cannot decrypt everything.
A producer could attempt to hide more by encrypting node references as well, but that would change the operations Petra is designed to support. If the relationship between bar and foo disappeared, a downstream producer might not know how to place the upstream record in the larger artifact. If all fields were packed into one ciphertext, a consumer would have to choose between receiving too much information and receiving too little. Petra instead makes a particular compromise: protect semantic values at fine granularity and expose the structural scaffolding needed for exchange.
What the policy protects—and what it cannot decide
The role example is a form of least disclosure, but it should not be mistaken for a complete definition of useful access. A vulnerability scanner that can read versions but not the component names or affected relationships may still be unable to answer its question. A licensing consumer that can read a license string without knowing which dependency it belongs to may receive data that is technically authorized but practically ambiguous. Petra can apply the cryptographic rule to the selected nodes; it does not interpret whether the resulting view is sufficient for a human or an analysis tool.
That limitation follows from Petra’s deliberate separation between structure and meaning. The system treats an SBOM as a collection of claims arranged in a tree. It can bind a policy to a path and enforce the decryption condition. It does not automatically understand the semantics of every schema or recognize that two fields must be visible together for a regulatory conclusion to be meaningful. A semantic-aware policy layer could improve that situation, but it is discussed as future work rather than as an existing capability.
The same separation applies to collusion. Petra uses CP-ABE because the decryption key for a protected node must carry the attributes needed to satisfy its policy. Two consumers who each hold only part of the required authority are intended not to be able to combine their partial access into a valid key. This is the collusion-resistance property the paper relies on. It is meaningful under the assumptions of the selected CP-ABE scheme and its implementation; it is not a guarantee that consumers cannot share plaintext they were individually authorized to read.
That last distinction is important. Once a consumer can decrypt a field, Petra cannot make the consumer forget it or prevent them from copying it. Selective encryption reduces unauthorized access to protected values in transit and at rest, but it does not transform an authorized reader into a perfectly controlled computing environment. The producer still has to decide which parties deserve access and how much information can safely be entrusted to them.
There are also inference risks even when no one obtains an authorized plaintext. Low-entropy values, such as a license chosen from a limited catalogue, are tempting targets for dictionary attacks if a cryptographic representation can be compared against guessed values. Petra’s later commitment and hashing construction uses randomized material to make such comparisons harder, and non-deterministic encryption makes it less useful to correlate equivalent fields across different SBOMs. Padding can further reduce clues from field length, but it adds storage cost.
Thus “confidential” has a precise meaning in Petra. It means that semantic claims are disclosed according to attribute-based policies, not that the document’s shape, relationships, or every policy implication is invisible. The system’s design is strongest when the visible structure is itself acceptable to the producer and the authorized views are sufficient for the jobs consumers must perform. It is weaker when the structure leaks a sensitive fact, when a policy fragments a task across inaccessible fields, or when the KMS assigns attributes incorrectly.
The tree from the previous discussion makes this mechanism possible: each claim has a location, each location can carry a policy, and the relationships remain available to parties with different keys. But selective encryption alone leaves an unanswered question. If a consumer sees a protected tree, how can they know that the generator did not remove an inconvenient claim before applying the policy, or that a downstream distributor did not substitute a different redacted copy? The next layer of Petra addresses that question by binding the protected view to evidence about the tree that existed before redaction.