Artifact-centric workflows describe possible executions of a business process through constraints expressed from the point of view of the documents exchanged between principals. A sequence of manipulations is deemed valid as long as every document in the workflow follows its prescribed lifecycle at all steps of the process. So far, establishing that a given workflow complies with artifact lifecycles has mostly been done through static verification, or by assuming a centralized access to all artifacts where these constraints can be monitored and enforced. We present in this paper an alternate method of enforcing document lifecycles that requires neither static verification nor single-point access. Rather, the document itself is designed to carry fragments of its history, protected from tampering using hashing and public-key encryption. Any principal involved in the process can verify at any time that a document’s history complies with a given lifecycle. Moreover, the proposed system also enforces access permissions: not all actions are visible to all principals, and one can only modify and verify what one is allowed to observe.
1. Decentralized Enforcement
of Artifact Lifecycles
Sylvain Hallé, Raphaël Khoury,
Yliès Falcone and Antoine El-Hokayem
Université du Québec à Chicoutimi, Canada
Université Grenoble Alpes, France
September 9th, 2016
BEST
PAPER
12. Observa�ons
The document follows a lifecycle
A test result cannot be changed once wri�en
X
An expensive drug must be approved by
the insurance company
$$
"Lifecycle
constraints"
13. Observa�ons
The document has condi�ons on its integrity
The pharmacologist
cannot write test results
The nurse cannot
prescribe drugs
X
X "Write
permissions"
14. Observa�ons
The document is subject to privacy concerns
The insurance company should
not access test results
The doctor should not know the pa�ent's
policy number
X
X "Read
permissions"
15. How can I be sure that these
rules are being followed?
18. Solu�on B
A�ach metadata to the document...
+
Use it to ensure confiden�ality and integrity
of its contents
and its history
19. Ingredients
Set of peersP { , , , , }
G Set of groups
M : P × G → {⊤,⊥} Membership func�on
A Set of ac�ons. Each ac�on is a func�on
a : D → D
D Set of documents
𝔹 Set of binary strings (e.g. hash values)
20. A document lifecycle specifies what ac�ons peers
are allowed to make on a document and
in which order
δ Lifecycle func�on for group g ∈ Gg
δ : S* → {⊤,⊥}g
For a peer-ac�on sequence s ∈ S*,
δ (s) = ⊤g ⇔
s complies with the lifecycle constraints
21. To ensure confiden�ality, ac�ons in the sequence
will be encrypted.
ħ Hash func�on
Public-key encryp�on/decryp�on func�onsD,E
Each group and each peer has a pair of
public-private keys.
KU, KV, KU, KV,
, ...,,,
22. To ensure confiden�ality, ac�ons in the sequence
will be encrypted.
An ac�on a ∈ A will actually be recorded as:
⟨E[K , a],p,g,b⟩U,g
All peers can see that some ac�on was
executed
Only members of g can know exactly
which one (by decryp�ng with K )
The set S is actually 𝔹 × P × G × 𝔹
V,g
⇒
?
23. The contents of a peer-ac�on are protected
by a digest
⟨a,p,g,b⟩ ∈ 𝔹 × P × G × 𝔹
Encrypted
ac�on Who is doing it
On behalf of which group
Digest
How is it computed?
24. ⟨a',p',g',b'⟩.Suppose that the last peer ac�on is
Peer p now wants to perform ac�on a
on behalf of group g.
The peer ac�on to append to the sequence is:
where
⟨E[K , a],p,g,b⟩U,g
b = E[K , ħ(b' ⋅ E[K , a] ⋅ g)]V,p U,g
25. When receiving a peer-ac�on sequence, each
peer can check its validity, star�ng from the end.
... , ⟨a',p',g',b'⟩, ⟨a,p,g,b⟩
Step 1. Check that M(p,g) = ⊤.
Step 2. Check that D[K , b] = ħ(b' ⋅ a ⋅ g)U,p
This makes sure that:
p has done the last ac�on
on behalf of group g (to which he belongs)
the last digest was indeed b'
26. Once the sequence is deemed valid, a peer can
check the lifecycle func�on of a group g that
he belongs to.
Step 1. For every peer ac�on ⟨a',p',g',b'⟩ where
g = g', compute a = D[K , a'].
This yields a peer-ac�on sequence s where the
ac�ons of group g appear in clear.
Step 2. Check that δ (s) = ⊤.
V,g
g
27. ?
X
Tampering with the sequence
can be detected by any peer
Replacing an ac�on/peer by another
Dele�ng/inser�ng an ac�on
Even without knowing the ac�on
Compliance with the lifecycle
can be checked by any peer (of
the same group)
Can choose to reject a document that
violates the spec
28. The amount of work on each new ac�on is
constant
Two encryp�ons, one hash
Applied on a string of constant length
Checking the sequence is linear
The lifecycle func�on is arbitrary
Considered as a "black box" throughout
Can use LTL, FSM, BPMN, ...
What about read/write permissions?
29. Suppose the exchange starts with an empty
document. Replaying the sequence of ac�ons
reconstructs the document up to its current state.
But you can only replay the ac�ons of the groups
you belong to!
$$$$$$
Groups control the parts of the document that
peers can read and write
The "document" is not necessary; the peer-
ac�on sequence is sufficient
30. ARTICHOKE
Implementa�on of these concepts in PHP for
PDF forms
Uses hidden form fields to store peer-ac�on
sequence (encoded as base-64)
MD5 for hashing, RSA for encryp�on
32. ARTICHOKE
$ artichoke Form.pdf dump
Form fields
-----------
F1 foo
F2 bar
Peer-action sequence
--------------------
Alice W|F1|foo Rm/MRSzK...
Bob W|F2|for kEvrkC+e...
35. The complete trace must be kept forever
Could we trim a prefix a�er some �me?
Can detect viola�ons, but not prevent them
A peer can choose to accept a tampered document
Documents can be copied
Divergent histories can be created
Invent sufficient condi�ons to prevent this?
Ac�ons can be guessed
Try them all un�l you find the one that works
Mi�gated by the size of A