These are the slides of a talk I gave at SRI International about one of my journal papers (http://bit.ly/JLAP12). The idea is to automatically synthesise orchestrators between stateful services that might be incompatible in signature, behavior and security protocols while avoiding deadlocks, livelocks and secrecy attacks

1. Synthesis of secure adaptors
for stateful services
J. Antonio Martín and Ernesto Pimentel
University of Málaga
SRI International, 2012
Paper: http://bit.ly/JLAP12

2. Motivation
● We deal with stateful services, i.e., services with behaviour
● Web Services have security policies
○ WS-Security, WS-SecureConversation, WS-Policy, ...
● Incompatible services send and receive incompatible
cryptographic messages
● We want to deal with incompatible policies and
incompatible behaviour (which arises deadlocks and
livelocks between these stateful services)
client

3. Example: Stateful services
Service a
Service b
Encoded in Crypto-CCS

4. Solution: adaptation
● Deploy an adaptor in the middle of the communication
which adapts incompatibilities in signature, behaviour
and security
● Behavioural adaptation is based on receiving, rearrange
and forward messages at the appropriate time
● Security adaptation extends behavioural adaptation with
symmetric and asymmetric cryptography and digests
through hashing
Get flickr API key
client adaptor Request Frob
Handle Token...

5. Example: Adaptor
Adaptor
Service a
Service b

6. Example: Adaptor
Adaptor
Service a
Service b

7. Solution: adaptation contracts
● An adaptor is abstractly specified by a security adaptation
contract (SAC)
● The synthesis process takes a contract and returns
a deadlock/livelock-free adaptor
● Secrecy properties are verified over the system and, if
needed, the adaptor is automatically refined to preserve
them
client adaptor
synthesis process
contract

8. Overview

9. Overview

10. Example: Incompatible services
Service a
Service b

11. Overview

12. Example: Incompatible services
Service a
Service b

13. Example: Incompatible services
Service a
Service b
HOW:
send! could match
with either
anonymous?, des?,
pub_rsa? or
priv_rsa?

14. Example: Incompatible services
Service a
Service b
HOW:
send! could match
with either
anonymous?, des?,
pub_rsa? or
priv_rsa?
I have the user
U and pass K

15. Example: Incompatible services
Service a
Service b
HOW:
send! could match
with either
anonymous?, des?,
pub_rsa? or
priv_rsa? Goal:
pass info M
I have the user from b to a
U and pass K

16. Example: Incompatible services
Service a
Service b
HOW:
send! could match
with either
anonymous?, des?,
pub_rsa? or
priv_rsa? Goal:
pass info M
I have the user from b to a
U and pass K
Privacy req.:
M should not be
disclosed

17. Adaptation contract
Service a
Service b
Sec. Adaptation Contract
anonymous!M^ < send?M
public_key! <
...
E0 VLTS

18. Adaptation contract
Service a
Service b
Sec. Adaptation Contract
anonymous!M^ < send?M
public_key! <
...
E0 VLTS

19. Adaptation contract, E0
Service a
Service b
Sec. Adaptation Contract
anonymous!M^ < send?M
public_key! <
login!U^,E(K^,U^) <
des!E(K^, M^) < send?M
...
E0 = [k/K, u/U,...] VLTS

20. Adaptation contract, VLTS
Service a
Service b
Sec. Adaptation Contract
1. anonymous!M^ < send?M
2. public_key! <
3. login!U^,E(K^,U^) <
4. des!E(K^, M^) < send?M
...
E0 = [k/K, u/U,...] VLTS
}

21. Overview

22. Interactions compliant with SAC
Service a
Service b
Adaptor
Sec. Adaptation Contract
1. anonymous!M^ < send?M
2. public_key! <
3. login!U^,E(K^,U^) <

23. Deadlock free synthesis
Adaptor
Service a
Service b
SAC

24. Deadlock free synthesis
Adaptor
Service a
Service b
SAC

25. Deadlock free synthesis
Adaptor
Service a
Service b
SAC

26. Overview

27. Secrecy property
Service a
Service b
● What do you want to protect?
● Which channels are subject to attack?
○ Restricted Dolev-Yao model
● Which information is public?

28. Secrecy property
Service a
Service b
Le - Actions not eavesdroppable
by the attacker
La - Actions not accessible nor
eavesdroppable by the attacker
p - Secrecy attack to avoid

29. Secrecy property
Service a
Service b
In our toy example:
La, Le: the attacker can only adaptor
avesdrop actions of service a
p: The attacker should not learn M
In other words, passive attacker and the
adaptor acts as a wrapper around service b

30. Partial model checking
Service a
Service b
(thanks to partial model-checking)

31. Verification
Adaptor
Service a
Service b
Attack

32. Refinement
Adaptor
Service a
Service b

33. Secure security adaptor
Adaptor
Service a
Service b
SAC

34. Contribution
● Adaptation of services with complex behaviors and security
policies in such a way that:
○ We avoid undesirable situations as deadlocks and livelocks
○ The adaptor is able to decompose and recompose messages
according to the interfaces and security policies of the services
involved
○ It is formally proved that the given secrecy attack is avoided
● The adaptation is specified by an abstract security adaptation
contract which expresses:
○ The initial information required for the adaptation
○ The transformations required to proceed with a successful
communication
○ The security checks to perform throughout the communication

35. Thank you!
Paper: http://bit.ly/JLAP12 -- Thesis: http://bit.ly/jamartin-thesis

36. WS-Security
<?xml version="1.0" encoding="utf-8"?>
<S11:Envelope><S11:Header>
<wsse:Security> ● T, I, S, V, K, L and B
<wsu:Timestamp wsu:Id="T0">...</wsu:Timestamp>
<wsse:BinarySecurityToken ValueType="...#X509v3" are placeholders used
wsu:Id="X509Token">...
</wsse:BinarySecurityToken>
<xenc:EncryptedKey>...
for matching data in the
<xenc:ReferenceList>
<xenc:DataReference URI="#enc1"/>
messages received
</xenc:ReferenceList>
</xenc:EncryptedKey> and sent from the
<ds:Signature><ds:SignedInfo>...
<ds:Reference URI="#T0">... T, adaptor
<ds:DigestValue>LyLsF094Pi4wP...</ds:
DigestValue>
</ds:Reference> I,
<ds:Reference URI="#body">...
<ds:DigestValue>LyLsF094i4wPU...</ds: Pk(S),
DigestValue>
</ds:Reference>
</ds:SignedInfo>
penc(V,
<ds:SignatureValue>Hp1ZkmFZ/2kQ...</ds:
SignatureValue>
Hash(cat(I,Pk(S)))),
<ds:KeyInfo>
<wsse:SecurityTokenReference> enc(K,L),
<wsse:Reference URI="#X509Token"/>
</wsse:SecurityTokenReference> Hash(T),
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
Hash(B),
</S11:Header>
<S11:Body wsu:Id="body">
penc(S,cat(Hash(T),Hash(B)),
<xenc:EncryptedData wsu:Id="enc1">...</xenc:EncryptedData>...
</S11:Body></S11:Envelope> enc(L,B)

37. WS-Security
<?xml version="1.0" encoding="utf-8"?>
<S11:Envelope><S11:Header>
<wsse:Security> ● T, I, S, V, K, L and B
<wsu:Timestamp wsu:Id="T0">...</wsu:Timestamp>
<wsse:BinarySecurityToken ValueType="...#X509v3" are placeholders used
wsu:Id="X509Token">...
</wsse:BinarySecurityToken>
<xenc:EncryptedKey>...
for matching data in the
<xenc:ReferenceList>
<xenc:DataReference URI="#enc1"/>
messages received
</xenc:ReferenceList>
</xenc:EncryptedKey> and sent from the
<ds:Signature><ds:SignedInfo>...
<ds:Reference URI="#T0">... T, adaptor
<ds:DigestValue>LyLsF094Pi4wP...</ds:
DigestValue>
</ds:Reference> I,
<ds:Reference URI="#body">...
<ds:DigestValue>LyLsF094i4wPU...</ds: Pk(S),
DigestValue>
</ds:Reference>
</ds:SignedInfo>
penc(V,
<ds:SignatureValue>Hp1ZkmFZ/2kQ...</ds:
SignatureValue>
Hash(cat(I,Pk(S)))),
<ds:KeyInfo>
<wsse:SecurityTokenReference> enc(K,L),
<wsse:Reference URI="#X509Token"/>
</wsse:SecurityTokenReference> Hash(T),
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
Hash(B),
</S11:Header>
<S11:Body wsu:Id="body">
penc(S,cat(Hash(T),Hash(B)),
<xenc:EncryptedData wsu:Id="enc1">...</xenc:EncryptedData>...
</S11:Body></S11:Envelope> enc(L,B)

38. Applications