User Tools

Site Tools


pe-bpmn-editor_stereotypes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
pe-bpmn-editor_stereotypes [2020/03/03 15:41]
pullonen [Stereotypes]
pe-bpmn-editor_stereotypes [2020/03/03 15:46]
pullonen
Line 1: Line 1:
 ====== Stereotypes ====== ====== Stereotypes ======
- 
-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:​ [[pe-bpmn-editor/​communicationprotection|CommunicationProtection]] is a general goal stereotype and denotes any protected communication,​ whereas [[pe-bpmn-editor/​securechannel|SecureChannel]] is a channel that protects confidentiality and integrity of the communication. Another concrete instantiation of [[pe-bpmn-editor/​communicationprotection|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 [[pe-bpmn-editor/​pkpublic|PKPublic]] and [[pe-bpmn-editor/​pkprivate|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. Task stereotypes represent actions that are needed to use some privacy enhancing technology. 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. For example, if the goal is to protect confidentiality then the two actions needed are first to apply the protection (e.g. encrypt) and later in the process to remove the protection (e.g. decrypt). Each stereotype opens a sidebar menu to specify the necessary parameters and roles of the inputs and outputs. For example, for public key encryption stereotype [[pe-bpmn-editor/​pkencrypt|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. [[pe-bpmn-editor/​sscomputation|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 
-[[pe-bpmn-editor/​sscomputation|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 ( [[pe-bpmn-editor/​gcgarble|GCGarble]] ) and the other uses the garbled circuit to actually get the outcome ( [[pe-bpmn-editor/​gcevaluate|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 [[pe-bpmn-editor/​restrictions|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. 
  
 ===== Technologies and their stereotypes ===== ===== Technologies and their stereotypes =====
Line 69: Line 50:
  
 [[pe-bpmn-editor_dimensionalityreduction|DimensionalityReduction]] stereotype was considered to cover the case when only parts (feature vectors) of the input picture data are used in the computation. However, this stereotype is deprecated. [[pe-bpmn-editor_dimensionalityreduction|DimensionalityReduction]] stereotype was considered to cover the case when only parts (feature vectors) of the input picture data are used in the computation. However, this stereotype is deprecated.
 +
 +===== Logic Behind The Stereotypes =====
 +
 +
 +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:​ [[pe-bpmn-editor/​communicationprotection|CommunicationProtection]] is a general goal stereotype and denotes any protected communication,​ whereas [[pe-bpmn-editor/​securechannel|SecureChannel]] is a channel that protects confidentiality and integrity of the communication. Another concrete instantiation of [[pe-bpmn-editor/​communicationprotection|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 [[pe-bpmn-editor/​pkpublic|PKPublic]] and [[pe-bpmn-editor/​pkprivate|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. Task stereotypes represent actions that are needed to use some privacy enhancing technology. 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. For example, if the goal is to protect confidentiality then the two actions needed are first to apply the protection (e.g. encrypt) and later in the process to remove the protection (e.g. decrypt). Each stereotype opens a sidebar menu to specify the necessary parameters and roles of the inputs and outputs. For example, for public key encryption stereotype [[pe-bpmn-editor/​pkencrypt|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. [[pe-bpmn-editor/​sscomputation|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
 +[[pe-bpmn-editor/​sscomputation|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 ( [[pe-bpmn-editor/​gcgarble|GCGarble]] ) and the other uses the garbled circuit to actually get the outcome ( [[pe-bpmn-editor/​gcevaluate|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 [[pe-bpmn-editor/​restrictions|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.
 +
  
  
pe-bpmn-editor_stereotypes.txt ยท Last modified: 2020/07/15 15:30 by pullonen