User Tools

Site Tools


BPMN leaks-when analysis

In BPMN leaks-when analysis the input is a BPMN model with annotations in pseudocode to write out how different components are related.

Annotating the model

The BPMN leaks-when analysis uses the SQL privacy editor as an interface although its input language is not SQL. All tasks that transform the data are annotated to show which components of the inputs are used to compute which outputs and to give names to the computations.

Running the analysis

BPMN leaks-when analysis is accessible from the SQL privacy editor and can be activated by clicking the respective button.

The analysis output is a table that summarizes which components of the inputs flow to the outputs. The cells in the table summarize the conditions and filters that the data passes. For data that always flows to the output there were no restrictive filters in the flow. The cell value never means that this output is not affected by that input. Finally, the if condition indicates that the flow is conditional and the passed filters can be seen when hovering over the cell. In addition, everything sent through the network (message flows) is summarized in a separate row for the potential network observer.

Source code

The source code of the analysis tool is available at pleak-leaks-when-analysis repository. The user interface of the analysis tool is accessible through pleak-sql-editor.


Computation scripts are only added to tasks. Most tasks are expected to have the respective output data object defined by the scripts. The only difference are the sending tasks that have no script and the task before an exclusive gateway (that task defines the predicate for the gateway). In addition, if PE-BPMN stereotypes are used then some of them result in default scripts - e.g. encryption tasks.

The main functions of interest are names filter_filterName where the prefix filter distingusihes these as the filtering functions collected to the analysis output with the predicate data.

In general, the lines of code look like: <output_data_name>.<field_in_output_data> = function(<input_data_name>.<field_in_input_data>, …, <input_data_name>.<field_in_input_data>)

For filters the function is called filter_<filterName>

For the predicate tasks (before the starting exclusive gateway) the script is just Predicate_name(<input_data_name>.<field_in_input_data>, …, <input_data_name>.<field_in_input_data>)

In addition to the filters the lists have special syntax where new objects can be appended and taken out later.


Association lists are a GADT “(keytype * valuetype) assoclist” with the following six operations:

  • nil : (keytype * valuetype) assoclist
  • add: keytype → valuetype → (keytype * valuetype) assoclist → (keytype * valuetype) assoclist
  • update : keytype → valuetype → (keytype * valuetype) assoclist → (keytype * valuetype) assoclist
  • find : keytype → (keytype * valuetype) assoclist → valuetype
  • endsWith : keytype → (keytype * valuetype) assoclist → bool /* note that this probably used in the opposite direction in the model */
  • contains : keytype → (keytype * valuetype) assoclist → bool

They satisfy the following equalities:

  • endsWith(_, nil) = false
  • contains(_, nil) = false
  • endsWith(K, add(K', _, L)) = (K == K')
  • endsWith(K, update(, _, L)) = endsWith(K, L)
  • contains(K, add(K', _, L)) = (K == K') || contains(K, L)
  • contains(K, update(_, _, L)) = contains(K, L)
  • find(_, nil) = bottom
  • find(K, add(K', V, L)) = if K == K' then V else find(K, L)
  • find(K, update(K', V, L)) = if contains(K, L) then (if K = K' then V else find(K, L)) else bottom


  • No cycles in the model
  • Only one regular start event (other pools must start with message start event). Additional start events may be present in subprocesses.
  • Task before a starting exclusive gateway has no output and can only contain a predicate script
  • Sending task also has no output and no script, the sent data is the input to the task
  • Data is received through message catch events
  • All other tasks should have some data inputs and at least one output
  • All data objects on the model must have unique names (except the data sent over the network - the uniqueness is still important for the analyzer but there is a translator component that can add this)
  • Data object names can have no spaces (use _ for example)
  • All message flows can carry one data object

Stereotype support

BPMN leaks-when analysis has limited support for PE-BPMN stereotypes. For tasks it supports SKEncrypt and SKDecrypt as well as attribute based encryption. In addition, it can take the SecureChannel stereotype into account for analysing the values available on the network.

Using the stereotypes means that the script in BPMN leaks-when is left empty bu the user and there is a PE-BPMN stereotype attached to the task in the PE-BPMN editor. The roles of the inputs (e.g. plaintext and the key) are determined based on the stereotype settings. We assume that the input data has a field called “data” and the key data object has a field called “key”. Hence, the encryption task encrypts the field “data” with the key from field “key” and puts the result into the output field “data”. The rest of the fields in the plaintext input are copied to the output with the same names as they had for the input.

Decryption works analogously with the fields with the same name. Decryption only succeeds when the right key is used.

Note that the model that correctly uses stereotypes for BPMN leaks-when analysis may not be valid for PE-BPMN analysis as the latter does not work with the inner structures of the data.

bpmn-leaks-when-analysis.txt · Last modified: 2020/02/19 09:16 by pullonen