Nonreputiation - Implementing information security in the DRA4WfMS

Chapter 4. DRA4WfMS

4.2 Implementing information security in the DRA4WfMS

4.2.3 Nonreputiation

We propose a cascade-based method in the DRA4WfMS to embed digital signatures in a DRA4WfMS document as described in 4.1.1 and 4.1.2. With the help of the AEA, each participant must embed a digital signature that signs his/her execution result and digital signatures embedded by his predecessor activities (or activity). Thus, the participant cannot repudiate the execution result of him/herself and his/her predecessors.

Also, all of his/her predecessors must sign the embedded signatures of their

predecessors. According to this recursive process, each participant cannot repudiate the execution of all of his/her ancestors.

A DRA4WfMS document contains many CERs, each of which has its own nonreputiation scope that consists of a set of CERs. If a CER  has a nonreputiation scope , then the participant who generated the CER  cannot deny having received a DRA4WfMS document containing CERs in , and accordingly generates . Algorithm 1 shows how to compute the nonreputiation scope of a CER in a DRA4WfMS document.

Algorithm 1. Deriving the nonreputiation scope of a CER in a DRA4WfMS document.

Input: A DRA4WfMS document D and one of the CERs in D, .

Output: A set  containing CERs in D.

(1) Let =.

(2) = and Changes=True.

(3) While (Changes==True) { Changes=False.

For each CER  in  {

Let  be the set of CERs whose signatures are signed by .

If ( – ) then { Changes=True.

=.

} }

}

Header section

Application definition section

Unique process id

Workflow definition section

Security definition section

A digital signature

Activity execution result section

Def

^ee

Def

^ee _{i A}₀

Figure 22. Architecture of a DRA4WfMS document

4.3 Syntax of the DRA4WfMS Document

The syntax of the DRA4WfMS document is designed according to the security requirements described in Section 1 as well as the operational models described in Section 4.1. Before presenting the detailed syntax of a DRA4WfMS document, we first present its general syntactic form (see Figure 22). A DRA4WfMS document consists of three sections: the header, application definition, and activity execution result. The application definition section actually represents a secured initial DRA4WfMS document, ({Def}^ee, [{Def}^ee]_Pri(A₀₎), which is defined in Section 4.1 and contains two subsections: workflow and security definitions, and a digital signature, [{Def}^ee]_Pri(A₀₎. The last activity execution result section consists of some CERs appended after executing the activities. Figure 23 shows the syntactic structure of a DRA4WfMS document, which is an XML document that comprises the following sections:

1. Header section: Since a DRA4WfMS document is also an XML document, it should begin with an XML declaration that specifies the version of XML being used (e.g., <?xml version="1.0"?>; see the first line of Figure 23) and the start tag

(e.g., <DRA4WfMS:DRA4WfMS

xmlns:DRA4WfMS="http://www.DRA4WfMS.com/2010">). Like an XML document, a DRA4WfMS document contains many elements delimited by start and end tags.

2. Unique process id: As mentioned above, the use of a unique process id supports multiple instances of a workflow process and resists replay attacks. Initiating a

DRA4WfMS workflow process should generate a unique process id for it. The value of attribute “Id” in the <UID> element is the unique process id.

3. Workflow definition section: This section defines the activities in the workflow process and the control and data flows among them. For each activity we include information about the starting and stopping conditions, the users who are allowed to participate, and the tools and/or data needed to complete this activity. The related information is embedded in the XML element <WorkflowDefinition>.

4. Security definition section: This section defines the <SecurityDefinition> element.

Some of the elements should be encrypted during the transmission of the DRA4WfMS document, and hence digital signatures need to be embedded in a DRA4WfMS document. The first part is a <SignatureKeyIssuer> element that is used to specify what types of keys are allowed to generate the digital signatures embedded in the DRA4WfMS document. This element shows the related information about the issuer of these keys. We employ the standard of X.509 certificates [114], which defines its attributes: “C”, “S”, “L”, “O”, “OU”, and “CN”

represent “country”, “stateName”, “localityName”, “organizationUnit”,

“organizationName”, and “commonName”, respectively. The second part includes the definitions of the cryptographic algorithms and security keys that will be used to encrypt and decrypt data. These are defined in the <KeyDefinitions> and

<AlgorithmDefinitions> elements. The other part of this section contains descriptions of how to encrypt and decrypt data based on the element-wise encryption scheme, as defined in the <EncryptionDefinitions> element.

5. Activity execution result section: Since the DRA4WfMS is a document-routing-based WfMS, all of the execution results of the activities, digital signatures, and timestamps should be recorded therein. Each CER is a <CER>

</SecurityDefinition>

<CERs>

Figure 23. XML-based syntax of a DRA4WfMS document

We now present the details of each section of a DRA4WfMS document.

4.3.1 Workflow Definition Section

The workflow definition section comprises three main parts: definitions for participants (<Participants> element), definitions for activities (<Activities> element), and definitions for transitions (<Transitions> element) (see Figure 24). We use the BNF (Backus Naur Form) form to show syntax definitions in this dissertation. We adopt the XPDL [22] of the WfMC to define the control flow in DRA4WfMS documents.

Thus, the <Transitions> element is identical to that in XPDL. XPDL contains several types of activity, but we only need to use the generic activity of XPDL in DRA4WfMS³. Thus, the <Activity> element contains <Description>, <Performers>, and

<TransitionRestrictions> elements as defined in XPDL. The <Description> element is the textual description of the activity, and the <Performers> element contains links to the <Participant> element. We extend the <Participant> element of XPDL because the system needs to infer the participants in the activities from the personnel and organization databases (see Section 4.3.1.1). Moreover, because a DRA4WfMS document needs to store the presentation of the working screens for all of the participants in all of the activities, we add a subelement <Presentation> to the

<Activity> element (see Section 4.3.1.2).

WorkflowDefinition

<WorkflowDefinition Id="String">

{Participant⁴}+

</Participants>

3 The route activity is used to support gateway notation in BPMN. The block activity is used to support the activity set. Also, we do not need to use the subflow activity in XPDL to define activities in DRA4WfMS.

4 See Section 4.3.1.1.

[<Description>String</Description>]

[<Performers>

{<Performer>Participant id<Performer>}+

</Performers>]

Presentation⁵

[<TransitionRestrictions>

{Join}

{<TransitionRef Id="String" [Name="String"]>}+

</Split>

Transition

<Transition Id="String" [Name="String"] From="String" To="String">

[<Description>String</Description>]

[<Condition [type="String"]>String</Condition>]

</Transition>

Figure 24. Syntax of the workflow definition

4.3.1.1 Participant Element

To support the operational models of the DRA4WfMS described in Section 4.1, we have to extend the definition power of the <Participant> element of XPDL because the participant should be either specified statically or inferred dynamically in our operational model. A participant can be specified statically by giving his or her name or

5 See Section 4.3.1.2.

id, or is dynamically inferred from data stored in databases and the execution states of the workflow process.

The first extension is the addition of two attributes in the <Participant> element (H_DB_Hyperlink and O_DB_Hyperlink) that link to the personnel and organization databases used to infer the participants in the activities. The organizational model of the DRA4WfMS is a tree (as shown in Figure 25) that can be easily specified by an XML document. Also, the personnel database is an XML document that refers to the

organization database (see

http://www.csie.ntnu.edu.tw/~ghhwang/DRA4WfMS/HDB.xml and http://www.csie.ntnu.edu.tw/~ghhwang/DRA4WfMS/ODB.xml).

- Organization - Human or role

ICLabCenter

H00040 H00013

Taipei Center

H00071 Boston Center

Cashier department Auditing division

H00030 H00019

Level 1

Level 2

Level 3

Figure 25. Example of the structure of organization units

Participant

<Participant Id="String" [Name="String"] H_DB_Hyperlink="String"

O_DB_Hyperlink=="String">

[<Description>String</Description>]

<ParticipantType

Type="(HUMAN|SYSTEM|ROLE|ORGANIZATIONAL_UNIT|RESOURCE_SET, RESOURCE)"/>

[<ExtendedAttributes>

<ExtendedAttribute Inference="String"/>

</ExtendedAttributes>]

</Participant>

Figure 26. Syntax of the participant element

Since the Participant element in a DRA4WfMS document is merely an extension of that in XPDL, it also uses the participant entity type defined in XPDL, which includes RESOURCE_SET, RESOURCE, ROLE, ORGANIZATIONAL UNIT, HUMAN, and SYSTEM (see the <ParticipantType> element in Figure 26). The second extension to XPDL is defining several inference functions to be used in the

<ExtendedAttributes> element of the Participant element. These inference functions are designed to infer entities in the databases linked by H_DB_Hyperlink and O_DB_Hyperlink as follows:

1. Hid(i): This function refers to a person whose Hid equals i. In the following example, the reference function is placed in the <ExtendedAttributes> element:

<Participant Id="A1_performer" Name="Sales manager"

H_DB_Hyperlink=http://iclab.ntnu.edu.tw/hdb.xml O_DB_Hyperlink="http://iclab.ntnu.edu.tw/odb.xml">

</ExtendedAttributes>

</Participant>

2. Name(n): This function returns a person whose name is n.

3. ORGANIZATION_ID(o): This function returns the organization unit whose id equals o.

4. ORGANIZATION_NAME(n): This function returns the organization unit whose name is n.

5. ACTIVITY_PARTICIPANT(a): This function returns the participant who performed actions in activity a.

6. ACTIVITY_PARTICIPANT(a,i): Since a workflow process may contain loops, this function returns the participant who performed the i-th execution of activity a.

7. Relation(r,p): In some cases we have to infer the participant indirectly from organizations and persons who were the participants in previous activities.

Referring to the example listed in Figure 27, “A2_performer” is the participant who is the level-two manager of employee Beckett. According to http://www.csie.ntnu.edu.tw/~ghhwang/DRA4WfMS/HDB.xml, this should be the person with an Hid of H00071. “A3_performer” refers to the level-one manager of the person who performed activity “Purchase_A1”. This function is detailed elsewhere [115]. The system designer could design his/her own “Relation”

function according to the specific requirements when using the DRA4WfMS.

However, all of the AEAs should have the same interpretation of the “Relation”

function.

<Participant Id="A2_performer" Name="Sales manager"

H_DB_Hyperlink="http://iclab.ntnu.edu.tw/hdb.xml"

O_DB_Hyperlink="http://iclab.ntnu.edu.tw/odb.xml">

</ExtendedAttributes>

</Participant>

<Participant Id="A3_performer" Name="Sales manager"

H_DB_Hyperlink="http://iclab.ntnu.edu.tw/hdb.xml"

O_DB_Hyperlink="http://iclab.ntnu.edu.tw/odb.xml">

<ExtendedAttribute Inference="Relation(Level_1_Manager,

Activity_Participant(Purchase_A1))"/>

</ExtendedAttributes>

</Participant>

Figure 27. Example XML document of a <Participant> element

4.3.1.2 Presentation Element

The <Presentation> element in the activity definition contains a sequence of input and output user interface objects. The input objects represent the inputs from the participant in the activity, and are stored in the activity execution result section. An input object can be a text field, a text area, a single-selection button, a multiple-selection button, a check box, or a file-upload field. The output objects represent components that should be shown to the participant in the activity via the working screen. An output object can be text, a picture, a file, a hyperlink, or a link to the element in the activity execution results of previously executed activities. Detailed definitions of the input and output objects are available elsewhere [115]. Figure 28 and Figure 29 show the syntax and an example of the <Presentation> element, respectively.

Presentation

{(Input|Output)}+

</Presentation>

Input

<Input Name="String" Type="String" />

Output

<Output Name="String" Type="String">String</Output>

Figure 28. Syntax of a <Presentation> element

<Output Name="COM1 Report" Type="Text">$COM1_Quantity</Output>

<Output Name="COM2 Report" Type="Text">$COM2_Quantity</Output>

<Output Name="COM2 Report" Type="Text">Report:</Output>

</Presentation>

Figure 29. Example of a <Presentation> element

4.3.2 Security Definition Section

Since a DRA4WfMS document may contain confidential data and be transmitted on a public network such as the Internet, the data therein must be encrypted. Both the workflow definition and activity execution results might need to be kept confidential. It is therefore necessary to provide a way for the workflow designer to specify how to perform element-wise encryption on these data.

4.3.2.1 Key and Algorithm Definitions

The security definition section contains some subsections. The key definition section defines keys that are referenced in the encryption and decryption processes.

There are two types of key definitions: (1) defining the keys statically, where the name and location of the key is specified explicitly (see the first example in Figure 30), which is achieved using the syntax of the key definition section presented in document security language (DSL) [20]; and (2) defining the key according to the inference functions defined in the <Participant> element (see the second example in Figure 30), in which case attributes of the hyperlinks for the personnel and organization databases should be present.

<!—To define the key statically-->

<KeyName>ghhwang.public.key</KeyName>

</KeyDefinition>

<!—To define the key according to inference functions-->

<KeyDefinition KeyLink="Activity_A2_Performer" KeyType="PUBLIC"

H_DB_Hyperlink="http://iclab.ntnu.edu.tw/hdb.xml"

O_DB_Hyperlink="http://iclab.ntnu.edu.tw/odb.xml">

<ExtendedAttribute Inference="Relation(Level_1_Manager,

Activity_Participant(Purchase_A1))"/>

</ExtendedAttributes>

</KeyDefinition>

Figure 30. Examples of key definitions

The algorithm definition section defines the algorithms that are referenced in the encryption and decryption processes using the syntax of the algorithm definition section presented in DSL [20], as shown in the example given in Figure 31.

<AlgorithmId>http://www.w3.org/2001/04/xmlenc#tripledes-cbc</AlgorithmId>

</AlgorithmDefinition>

Figure 31. Example of algorithm definition

4.3.2.2 Encryption Definition

According to the requirements of element-wise encryption, different keys and algorithms may need to be applied to secure different parts of a DRA4WfMS document.

The details of encryption and decryption are specified in the encryption definition section. As mentioned in Section 4.1.2, the workflow definition (i.e., the <APDefinition>

element shown in Figure 23) may need to be secured. However, we do not have to involve the security requirement of the <APDefinition> element in a DRA4WfMS

document, since this element is created statically before the execution of the workflow process. We can instead use a security tool such as the DSL API to implement the required encryption [116].

However, the CERs are embedded in a DRA4WfMS document dynamically during the run-time of the workflow process. We need to consider how to perform element-wise encryption for CERs in a DRA4WfMS document. Referring to the syntax used in Figure 32, the <EncryptionDefinitions> element contains single or multiple

<EncryptionDefinition> elements that define the required element-wise encryption of a CER. The <CER> element defines the activity id and index of the target CER. The

<ElementwiseEncryptions> element contains some <ElementwiseEncryption>

elements, each of which contains the scope to which the encryption will be applied.

Each <SecurityPattern> element provides information about the cryptographic algorithm and keys that will be used to encrypt the execution result defined by the

<Scope> element.

The DRA4WfMS also supports a dynamic security policy where the security requirements can depend on the dynamic behavior of workflow execution. Several previous examples [105] have demonstrated that static methods of defining security policy in a workflow application, such as DSL [20], are insufficient. Herein we propose a method to define a dynamic security policy for the DRA4WfMS. It is fulfilled by embedding a <Condition> element in the <ElementwiseEncryption> element. If the

<Condition> element is absent from the <ElementwiseEncryption> element, the execution result specified by the <Scope> element should be encrypted by security schemas defined in all of the <SecurityPattern> elements. The execution result can be

encrypted multiple times using different algorithms and keys. Part of the element-wise encryption requirement is that the secured data can be decrypted by a limited set of people and groups. If a <Condition> element is included, we have to evaluate the Boolean predicate represented by the Inspector predicate before we proceed to the encryption process. The encryption process should be carried out only when the evaluation result of the Inspector predicate is True. We define the following expressions and functions that are used in the Inspector predicate to verify the dynamic behavior of the workflow processes:

 $ActivityId[Index].KeyName: This expression represents the value of one of the items in the execution result of a CER whose key name is KeyName. The associated activity id and index of the CER are ActivityId and Index, respectively.

 CheckFlow.ActivityExecuted(ActivityId). This Boolean function checks if an activity has been executed. The ActivityId parameter is the id of the target activity.

 CheckFlow.ActivityExecutedTimes(ActivityId). This function returns the number of times that an activity was executed (as an integer).

 ActivityParticipant(ActivityId). This function returns the id of the participant of activity ActivityId.

 isActivityParticipant(ActivityId, ParticipantId): This function returns True if ParticipantId is the participant of ActivityId.

These functions and the expressions defined in XML Path Language (XPath) 2.0 can be used to construct a Condition element [117]. XPath 2.0 allows the use of Boolean

“and” and “or” operations in logical expressions. The value-comparison operators are

“==”, “!=”, “<”, “<=”, “>”, and “>=”. For example, the predicate

“($A1[0].V1 >100) and CheckFlow.ActivityExecuted(A2)” checks if the execution result of the item with name V1 in activity A1 is greater than or equal to 100, and if A2 has been executed. Figure 33 provides an example of an

<EncryptionDefinition> element.

EncryptionDefinitions

EncryptionDefinition { EncryptionDefinition } </EncryptionDefinitions>

EncryptionDefinition

<CER id="ActivityID" [index="Integer"]/>

ElementwiseEncryption { ElementwiseEncryption } </ElementwiseEncryptions>

</EncryptionDefinition>

ElementwiseEncryption  <ElementwiseEncrytion>

Scope

<SecurityPatterns> SecurityPattern { SecurityPattern } </SecurityPatterns>

[ Condition ]

</ElementwiseEncryption>

Scope  <Scope> ALL </Scope> |

<EncryptionKey KeyLink="KeyLink" KeyType="(PUBLIC|PRIVATE)"/>

[<DecryptionKey KeyLink="KeyLink" KeyType="(PUBLIC|PRIVATE)"]/>

</Keys>

Figure 32. Syntax of encryption definition

<Scope><Name>$A1[0].Input</Name></Scope>

在文檔中工作流程管理系統與呼叫鍊的安全性架構 (頁 90-112)