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

2. $

3. $
DOCTOR
PATIENT
INSURANCE
COMPANY
PHARMACIST
NURSE

4. $
DOCTOR
PATIENT
INSURANCE
COMPANY
PHARMACIST
NURSE
DOCUMENT

5. $
The doctor fills in
the results of a
test
1

6. $
Based on the results,
the doctor adds a
prescrip�on for a drug
2

7. $
The pharmacist writes
the cost of the drug3 =
$$

8. $
The insurance company
approves the expense4

9. $
The pa�ent
acknowledges5

10. $
The nurse writes the
moment she gave the drug6

11. $$
Patient's
address
Insurance
policy #
Test results
Prescription
Cost
Insurance
approval
Timestamps

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?

16. $
Solu�on A
Centralized access to the document
All accesses and modifica�ons
are filtered and verified

17. $
Solu�on A
Centralized access to the document
Single point of failure
Must be trusted

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

31. ARTICHOKE
$ artichoke Form.pdf fill
-k private_key_Alice.pem
-p Alice
-o Form-filled.pdf
F1 foo

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...

33. ARTICHOKE
$ artichoke Form.pdf check *.pem
The lifecycle func�on can be any user-defined
PHP code

34. 50000
100000
150000
200000
250000
300000
350000
400000
450000
500000
100 150 200 250 300 350 400 450 500
Time(ms)
Operations
200
250
300
350
400
450
500
550
600
650
100 150 200 250 300 350 400 450 500
Time(ms)
Operations
14000
16000
18000
20000
22000
24000
26000
28000
30000
100 150 200 250 300 350 400 450 500
Filesize(B)
Operations
...wri�ng the sequence ...checking the sequence
Sequence size
Running �me for...

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

36. Thank you!
Ques�ons?
http://slideshare.net/sylvainhalle
http://leduotang.ca/sylvain
http://liflab.ca