Source-linked AI summary
Identification of Compositional Risks in Data Protection Impact Assessments and Beyond
Henrik Graßhoff, Meiko Jensen, Malte Hansen, Nils Gruschka
TL;DR
Distributed processor compositions can create privacy risks that individual assessments overlook. The paper proposes a privacy-preserving protocol to identify candidate constellations and integrate them into DPIA risk assessment. The protocol terminates, provides nodes with cusp-related information, and limits what focal points learn, but remains probabilistic and requires a shared standardised API for implementation.
Problem
Privacy risks can arise from processor compositions spanning multiple entities, while business confidentiality may prevent controllers from seeing the complete service composition.
Method
The paper proposes a privacy-preserving protocol that detects candidate processor constellations using distributed pseudonym aggregation without revealing service relationships.
Results
The protocol terminates, gives each node either cusp absence information or an upper bound on focal points, and limits focal-point knowledge about the detection.
Takeaways & Limitations
Detected candidates can be individually inspected for processing details and potential linkability to improve DPIA results.
Takeaways & Limitations
The protocol is probabilistic, with possible pseudonym collisions and Bloom-filter false positives that can create false detections or leave focal points undetected.
Abstract
from arXiv · showhide
When personal data is processed in a distributed manner by cooperating service providers, privacy risks may emerge solely from the choice of data processors included in the composition. For instance, different data processors may unknowingly rely on the same cloud provider, allowing for unintended linkability of personal data at that very provider. As such compositional risks to privacy are beyond the scope of each individual risk assessment, they are likely to be overseen when performing a data protection impact assessment. In this paper, we propose a novel protocol to detect and manage such compositional risks to privacy. Following an initial problem definition and requirements elicitation, we elaborate how our protocol identifies candidates for compositional risks and how this information may be used to improve the results of a data protection impact assessment over service compositions including multiple data processors.
1. Introduction and Motivation
DPIAs must document risks to data subjects, but risks can span multiple processors and arise from their composition rather than from any single processor.
- DPIAs document identified risks, their probability and damage assessments, and potential mitigation measures.
- Risks in distributed processing may span multiple data processors, whose participation in a joint DPIA may vary.
- Compositional privacy risks can result from the combination of processors rather than from individual processing activities.
- The paper proposes a protocol that identifies processor constellations potentially causing compositional risks while accounting for trust and business confidentiality.
- The paper proceeds from DPIA background and problem requirements to a graph model, distributed detection protocol, risk handling, and implementation discussion.
2. Background
DPIAs formally assess processing risks and mitigation measures, while increasingly distributed data sharing requires external data flows and processor-related risks to be included.
- DPIAs are mandatory before processing activities likely to create high risks to individuals’ rights and freedoms.
- A DPIA must systematically describe processing operations, assess resulting risks, and describe measures addressing those risks.
- DPIA methodologies and frameworks have been proposed by data protection authorities and scientific researchers, with some assessments publicly available.
- As processing involves more entities, DPIAs must include data flows and external risks, while controllers remain responsible for involved processors.
- Related cloud-computing research addresses confidentiality threats through process partitioning or detection and management of provider collusion.
3. Problem Statement
Compositional risks arise when processor combinations enable linkability or reconstruction across processing contexts, yet identifying them is complicated by incomplete composition visibility and confidentiality constraints.
- DPIA risk identification requires inputs from all processors because risks may reside with only some entities in a service composition.
- Compositional risks originate from the composition of processors and sub-processors rather than from one organisation’s processing modalities.
- A composed service contains a controller, processors, and recursively nested sub-processors, which may terminate at sink nodes.
- Compositional Risk Examples: Shared cloud sub-processors can receive the same customer data through different processors, enabling cross-dataset linkability.
- Compositional Risk Examples: Different masking schemes applied independently by processors can allow a shared cloud provider to reconstruct a complete credit card number.
- Compositional Risk Examples: Encrypted records and separately stored keys can create risk if a shared cloud provider links records from different processor accounts.
- Compositional Risk Identification: Identifying candidate constellations requires checking each candidate’s processing and potential linkability, typically through additional manual inspection.
- Compositional Risk Assessment versus Service Composition Confidentiality: Processor confidentiality can prevent controllers from collecting the complete composition, so detection must protect business partner identities and service relationships.
4. Detection Protocol
The proposed protocol abstracts service compositions as directed graphs and recursively aggregates privacy-preserving pseudonyms to detect potential compositional-risk focal points.
- The protocol transfers service-composition scenarios into a graph-theoretical setting before defining and analysing the detection procedure.
- A service interaction instance forms a finite, connected, directed graph with a source node representing the controller.
- A focal point has at least two incoming edges, and a cusp is a node with at least two distinct paths to that focal point.
- In the example composition, Cloud Provider is a focal point with Shipping Provider and Online Shop as its cusps.
4.1. Cryptographic Prerequisites
The protocol relies on Bloom filters for probabilistic cycle termination and blindable pseudonyms for unlinkability across protocol inquiries.
- Bloom Filters: Bloom filters use an m-bit array and k hash functions to test membership, permitting false positives but no false negatives.Their false-positive probability depends on m, k, and the number of added items.
- Bloom Filters: In this protocol, Bloom filters guarantee termination when service-interaction graphs contain cycles, at the cost of possible premature recursion termination.A false-positive membership test can therefore cause focal points to remain undetected.
- Blindable Pseudonyms: Blindable pseudonyms compute pseudonyms from a salt and secret key while allowing the salt to be transformed without revealing the key.The transformation preserves the ability to recover the original pseudonym from the blinded one and the blinding factor.
- Blindable Pseudonyms: Blindable pseudonyms prevent nodes from linking inquiries within one protocol execution or linking pseudonyms across different executions.The construction assumes practically negligible collisions when the salt or key remains fixed.
4.2. The Protocol
The protocol propagates blinded salts and Bloom filters through the service graph, recursively aggregates pseudonyms, and detects focal points from duplicate entries without revealing their identities or locations.
- Initialization: The source generates a random salt and empty Bloom filter, then propagates them to its children.Every party holds a secret key used to compute its pseudonym.
- Aggregation phase: Each node computes its pseudonym, records its key in the Bloom filter, blinds the salt, and recursively queries its children.Returned pseudonyms are unblinded, combined into a multiset, and sent back to the querying parent.
- Aggregation phase: Recursion stops at sinks or when the Bloom-filter membership test returns true, with an assessable false-positive probability.This termination condition prevents unbounded recursion in cyclic graphs.
- Focal-point detection: A node detects a focal point by checking duplicate pseudonyms after receiving multisets from all children.The node can infer that a focal point exists without learning its identity or graph location.
4.3. Analysis
The analysis assumes honest-but-curious participants and characterizes termination, bounded local knowledge, inquiry unlinkability, and focal-point concealment, while illustrating probabilistic failure modes and an example execution.
- Threat model: The analysis assumes every participant follows the protocol but attempts to exploit any knowledge leakage.This is the honest-but-curious threat model.
- Threat model and parameter choice: The protocol can produce false focal-point conclusions through pseudonym collisions and can miss focal points when Bloom-filter false positives stop recursion early.Parameter choices must balance correctness and computational feasibility, and are deferred to future work.
- Properties: The protocol terminates and gives each node either no-cusp information or an upper bound on its number of focal points.The Bloom-filter check prevents infinitely many recursive calls and supports testing for the absence of focal points.
- Properties: Salt blinding makes inquiries appear to carry random salts, preventing nodes from distinguishing whether inquiries belong to the same execution.A focal point that is not its own cusp does not learn that it is a focal point.
- Example: In the example, ordinary non-cusps find neither their own pseudonyms nor duplicates, while several nodes detect duplicates and J identifies itself as a focal point.Duplicates from children of non-cyclic focal points create additional overhead in the aggregated multisets.
5. Handling Compositional Risk Candidates
The protocol produces candidate data processors for compositional risks, but each candidate requires further inspection to determine whether a risk exists and how it should be handled. Available responses include accepting, mitigating, or eliminating the risk through changes to processors, data flows, privacy-enhancing technologies, or processing features.
- The protocol outputs data processors that may participate in compositional risks, rather than confirming that a risk exists.Candidates arise from their position in the data-processing network and require additional inspection.
- Each candidate must be manually inspected to assess the processed data, processing operation, potential linkability, and number of involved requests.
- The data controller is responsible for investigating and resolving compositional risks, although this task may be delegated to relevant subprocessors.
- Risk handling can accept the risk, mitigate it with additional privacy-enhancing technologies, or eliminate it through changes to the composition.Mitigation may add encryption, while elimination may change a subprocessor or remove data flows.
- Changing a cloud provider, removing data flows, or applying consistent masking can eliminate a linkability risk, but topology changes require rerunning the protocol.Removing processing can also reduce available processing features and conflict with business optimisation goals.
6. Discussion
The protocol still faces implementation, integration, governance, and participation challenges across heterogeneous and internationally distributed data-processing environments. Its practical deployment requires shared interfaces, integration with DPIA methods, and further examination of legal and organisational responsibilities.
- Implementing the protocol across entities with different IT systems requires a shared, standardised API.Data spaces may provide common data formats for data flows and risks, but not all scenarios involve participants in the same data space.
- International data sharing and subprocessors outside a common data space leave the platform for providing the protocol unresolved.
- The protocol must be integrated into privacy risk assessment methodologies and used to improve DPIA descriptions of data flows and subsequent risk assessment.This integration requires information exchange between controllers and processors about risks and measures.
- Applicability across worldwide privacy-impact-assessment regulations remains open because the approach relies on the GDPR hierarchy placing the data controller at the graph’s top.
- For joint controllership, the methodology assumes one joint controller leads the protocol while the others behave as normal data processors.
- The legal obligation of subprocessors to participate requires further examination, especially because authority weakens farther down the processing tree.
7. Conclusion and Future Work
The paper concludes that compositional privacy risks are difficult to evaluate in complex service-dependency graphs, particularly when multiple entities share a data processor. It presents a privacy-preserving detection protocol, discusses risk management, and identifies implementation and validation as future work.
- Multiple processing partners and their subprocessors form complex service-dependency graphs in which evaluating compositional privacy risks is non-trivial.
- Severe risks can arise when two or more entities use the same data processor in a processing network.
- The proposed protocol detects candidates for compositional risk manifestations without revealing relationships between entities and their subprocessors.
- The paper analyses the protocol’s reliability and privacy properties and discusses strategies for managing potential risks.
- Future work includes implementing and simulating the protocol, extending it with risk-mitigation measures, and assessing other scenarios and compositional-risk types.