PE-BPMN defines stereotypes for different tasks in privacy enhancing technologies so that they can be included in the BPMN model. The stereotypes are organized based on the taxonomy of privacy-enhancing technologies used to create PE-BPMN.

There are two message flow stereotypes: CommunicationProtection is a general goal stereotype and denotes any protected communication, whereas SecureChannel is a channel that protects confidentiality and integrity of the communication. Another concrete instantiation of CommunicationProtection could be something to mark anonymous communication.

We have also added data object stereotypes to be able to type check the models. At the moment we support two stereotypes PKPublic and PKPrivate that can be used to define a key pair for public key cryptography. The group notation of stereotypes is used to denote which keys belong to one key pair.

The rest of the stereotypes are task stereotypes and they are grouped based on the taxonomy. The respective menu appears when clicking a task in PE-BPMN editor. The goals that the task can have are data protection, data processing and entity authentication. Data protection has two possible targets: integrity and confidentiality protection. In data processing the targets are either privacy preserving or privacy adding computations. At the moment we have not implemented any stereotypes of the human-data interaction category. After choosing the goal it is possible to choose the concrete stereotype. Each stereotype opens a sidebar menu to specify the necessary parameters and roles of the inputs and outputs. For example, for PKEncrypt it is necessary to specify which input acts as the key and which as the plaintext.

One important parameter is the group of the computations. Some tasks form natural groups and are not meaningful on their own. For example, secure multiparty computation needs to be carried out by multiple parties simultaneously. In our solution each participant has their own computation task (e.g. SSComputation ) and these tasks form groups where the semantics is that the tasks actually collaboratively compute the required functionality. For example, if the stakeholders A and B both have a SSComputation task of group C then these two tasks can only be executed in parallel and the outputs of both tasks depend on the inputs of both tasks. In practice this corresponds to the case where A and B execute some collaborative computation protocol. In some cases the computations of all participants are the same and therefore the tasks in the group have the same stereotype. This is true for all secret sharing based technologies, moreover, in most cases the number of tasks in a group should correspond to the number of shares that there are. In others, the participants have distinct roles and we also have created distinct stereotypes for these tasks. However, for a meaningful use, these stereotypes still need to be grouped to state which operations belong together. For example, in garbled circuits technique, one participant creates the circuit ( GCGarble ) and the other uses the garbled circuit to actually get the outcome ( GCEvaluate ). In these cases the group should contain one of each separate task. The other such pairs are oblivious transfer (OT) and attestation of SGX technologies.

Not all stereotypes can be added to all tasks, for example there has to be suitable number of inputs and outputs. For some stereotypes, it can be that there are special roles that the inputs or outputs have. For example, an encryption operation has two distinct inputs - the key and the plaintext - that can be identified on the model. For some stereotypes the only restriction is that there must be a certain number of inputs or outputs. Implemented restrictions for currently used stereotypes are covered on restrictions page and under each stereotype. There are listed the number of expected inputs and outputs as well as parameters. In case the inputs or outputs have special roles, then they are also named in the table and the user interface allows to fix which data object has the specified role. At the moment the main parameters that we consider are the group of the computation and the script. If the parameter is specified only as a group then it is expected that the group is formed of only tasks of that type. In other cases, the groups formed of multiple separate tasks also specify the other expected stereotypes that should belong to the group.

Encryption is a way of protecting the confidentiality of some data by encoding it in a way that the message is restorable only to those that have the right keys. In addition, some encryption methods are homomorphic and allow to compute new values from encrypted values without removing the protection.

In secret key encryption both encryption and decryption use the same key. SKEncrypt task takes the paintext and a key and produces a ciphertext. SKDecrypt reverses encryption by taking the same key and the ciphertext and producing the plaintext. In case of homomorphic encryption, SKComputation can take ciphertext encrypted with the same key and produce a new ciphertext for the same key.

In public key encryption encryption and decryption use different components of the key pair. PKEncrypt task takes the paintext and a public key and produces a ciphertext. PKDecrypt reverses encryption by taking the private key from the same key pair and the ciphertext and producing the plaintext. In case of homomorphic encryption, PKComputation can take ciphertext encrypted with the same key and produce a new ciphertext for the same key.

We use PKPublic stereotype to denote the public key that can be known to anyone and PKPrivate to denote the private key that can only be known to parties that can decrypt.

Secure multiparty computation (MPC) techniques are methods that allow participants to protect their data and process it in a distributed manner while maintaining the confidentiality of all the inputs. The only information that is revealed about the inputs is the desired output of the computation. Common methods to achieve secure computation use either secret sharing or garbled circuits as a basis.

In Pleak we also consider a generic stereotype to denote secure multiparty computation - MPC. This considers the most straightforward use of secure computation where all participants that have input data also somehow participate in the computation and all tasks with MPC stereotype and executing the same computation are run in parallel. In addition, we expect that all inputs and outputs are public but different parties may have different inputs and outputs.

SSSharing is used to create shares and fix the threshold. SSComputation tasks are used to compute with secret shares. SSReconstruction is used to restore the shared value.

AddSSSharing is used to create additive shares. AddSSComputation tasks are used to compute with secret shares. AddSSReconstruction is used to restore the shared value.

FunSSSharing is used to create additive shares. FunSSComputation tasks are used to evaluate the shared function on a known point and get additive shares as outputs. FunSSReconstruction could be used to restore the shared function for function shares, but this functionality is not commonly used.

For Garbled circuits we consider two possibilities. One way is to have a pair of GCComputation stereotyoped tasks that correspond to the computation and are run in parallel.

The other possibility is to take the asymetric and not necessarily parallel execution of the protocol into account and have two distinct tasks GCGarble and GCEvaluate. Here, the garbling task generates the garbled circuit that is then sent to the evaluator. The evaluating party usually uses oblivious transfer to obtain the input encodings necessary for evaluating and then evaluates the circuit.

Oblivious transfer allows the receiver to obtain one of the inputs of the sender without the sender learning which input was queried. We represent this in two tasks OTSend and OTReceive that are either executed in parallel or have a message flow from sending task to the receiving task.

Intel Software Guard Extensions offer secure computations using a secure enclave on a special processor.

We use SGXProtect stereotype for tasks that prepare the inputs for SGX computation. The parameters of this task fix which SGX instance the inputs are intended. On the lane belonging to the machine with an SGX processor we have SGXComputation tasks that can either produce values that are protected (e.g. remain inside the SGX enclave) or values that become public for other processing than SGX.

A crucial component of SGX computation is the remote attestation where the parties giving inputs or otherwise interacting with the SGX machines can be convinced that their inputs will go to SGX and the code running in SGX is as expected. In that process the enclave runs the SGXAttestationEnclave task and the client runs SGXAttestationChallenge

In addition, we consider SGXQuoting to produce a signed confirmation of the enclave and SGXQuoteVerification that is a procedure run by the Intel service to verify the quote. These are a part of the attestation process and help to draw attention to the need of the additional Intel server if necessary.

At the moment we have two networking stereotypes that apply to message flows SecureChannel and CommunicationProtection. The latter is the general stereotype that denotes any form of PET applied to the transmission. However, the former is used for confidential communication channel (that also ensures integrity), e.g. what is achieved with TLS.

The DifferentialPrivacy stereotype can be used to denote tasks that deploy differential privacy as part of their computations. The stereotype allows to fix the parameters for differential privacy, however, at the moment these are not used by the analyzer. However, it will be interesting to consider these tasks when different analyzers are merged.