Synthesis of Secure Adaptors
-
Upload
jose-antonio-martin-baena -
Category
Technology
-
view
125 -
download
0
description
Transcript of Synthesis of Secure Adaptors
Synthesis of secure adaptorsfor stateful services
J. Antonio Martín and Ernesto PimentelUniversity of Málaga
SRI International, 2012
Paper: http://bit.ly/JLAP12
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
Example: Stateful services
Service aService b
Encoded in Crypto-CCS
Solution: adaptation
client adaptor
● 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 keyRequest Frob
Handle Token...
Example: Adaptor
Service bService a
Adaptor
Example: Adaptor
Service bService a
Adaptor
Solution: adaptation contracts
client
● 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
contract
adaptor
synthesis process
Overview
Overview
Example: Incompatible services
Service aService b
Overview
Example: Incompatible services
Service bService a
Example: Incompatible services
Service bService a
send! could match with either
anonymous?, des?, pub_rsa? or
priv_rsa?
HOW:
Example: Incompatible services
Service bService a
send! could match with either
anonymous?, des?, pub_rsa? or
priv_rsa?
HOW:
I have the user U and pass K
Example: Incompatible services
Service bService a
send! could match with either
anonymous?, des?, pub_rsa? or
priv_rsa?
HOW:
I have the user U and pass K
Goal:pass info M from b to a
Example: Incompatible services
Service bService a
send! could match with either
anonymous?, des?, pub_rsa? or
priv_rsa?
HOW:
I have the user U and pass K
Goal:pass info M from b to a
Privacy req.:M should not be
disclosed
Adaptation contract
Service bService a
anonymous!M^ < send?Mpublic_key! <
...
Sec. Adaptation Contract
VLTSE0
Adaptation contract
Service bService a
anonymous!M^ < send?Mpublic_key! <
...
Sec. Adaptation Contract
VLTSE0
Adaptation contract, E0
Service bService a
anonymous!M^ < send?Mpublic_key! <
login!U^,E(K^,U^) < des!E(K^, M^) < send?M
...
Sec. Adaptation Contract
VLTSE0 = [k/K, u/U,...]
Adaptation contract, VLTS
Service bService a
1. anonymous!M^ < send?M2. public_key! <
3. login!U^,E(K^,U^) < 4. des!E(K^, M^) < send?M
...
Sec. Adaptation Contract
VLTSE0 = [k/K, u/U,...]
}
Overview
Interactions compliant with SAC
Service bService a
Adaptor
1. anonymous!M^ < send?M2. public_key! <
3. login!U^,E(K^,U^) < 4. des!E(K^, M^) < send?M
...
Sec. Adaptation Contract
Deadlock free synthesis
Service bService a
SAC
Adaptor
Deadlock free synthesis
Service bService a
SAC
Adaptor
Deadlock free synthesis
Service bService a
SAC
Adaptor
Overview
Secrecy property
Service bService a
● What do you want to protect?● Which channels are subject to attack?
○ Restricted Dolev-Yao model● Which information is public?
Secrecy property
Service bService a
Le - Actions not eavesdroppable by the attackerLa - Actions not accessible nor eavesdroppable by the attackerp - Secrecy attack to avoid
Secrecy property
Service bService a
In our toy example: La, Le: the attacker can onlyavesdrop actions of service ap: The attacker should not learn MIn other words, passive attacker and the adaptor acts as a wrapper around service b
adaptor
Partial model checking
Service bService a
(thanks to partial model-checking)
Verification
Service bService a Adaptor
Attack
Refinement
Service bService a
Adaptor
Secure security adaptor
Service bService a
SAC
Adaptor
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
Thank you!Paper: http://bit.ly/JLAP12 -- Thesis: http://bit.ly/jamartin-thesis
WS-Security<?xml version="1.0" encoding="utf-8"?><S11:Envelope><S11:Header> <wsse:Security> <wsu:Timestamp wsu:Id="T0">...</wsu:Timestamp> <wsse:BinarySecurityToken ValueType="...#X509v3" wsu:Id="X509Token">... </wsse:BinarySecurityToken> <xenc:EncryptedKey>... <xenc:ReferenceList> <xenc:DataReference URI="#enc1"/> </xenc:ReferenceList> </xenc:EncryptedKey> <ds:Signature><ds:SignedInfo>... <ds:Reference URI="#T0">... <ds:DigestValue>LyLsF094Pi4wP...</ds:DigestValue> </ds:Reference> <ds:Reference URI="#body">... <ds:DigestValue>LyLsF094i4wPU...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Hp1ZkmFZ/2kQ...</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security></S11:Header><S11:Body wsu:Id="body"> <xenc:EncryptedData wsu:Id="enc1">...</xenc:EncryptedData>...</S11:Body></S11:Envelope>
T, I, Pk(S), penc(V, Hash(cat(I,Pk(S)))),enc(K,L), Hash(T), Hash(B),penc(S,cat(Hash(T),Hash(B)),enc(L,B)
● T, I, S, V, K, L and B are placeholders used for matching data in the messages received and sent from the adaptor
WS-Security<?xml version="1.0" encoding="utf-8"?><S11:Envelope><S11:Header> <wsse:Security> <wsu:Timestamp wsu:Id="T0">...</wsu:Timestamp> <wsse:BinarySecurityToken ValueType="...#X509v3" wsu:Id="X509Token">... </wsse:BinarySecurityToken> <xenc:EncryptedKey>... <xenc:ReferenceList> <xenc:DataReference URI="#enc1"/> </xenc:ReferenceList> </xenc:EncryptedKey> <ds:Signature><ds:SignedInfo>... <ds:Reference URI="#T0">... <ds:DigestValue>LyLsF094Pi4wP...</ds:DigestValue> </ds:Reference> <ds:Reference URI="#body">... <ds:DigestValue>LyLsF094i4wPU...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Hp1ZkmFZ/2kQ...</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security></S11:Header><S11:Body wsu:Id="body"> <xenc:EncryptedData wsu:Id="enc1">...</xenc:EncryptedData>...</S11:Body></S11:Envelope>
● T, I, S, V, K, L and B are placeholders used for matching data in the messages received and sent from the adaptorT,
I, Pk(S), penc(V, Hash(cat(I,Pk(S)))),enc(K,L), Hash(T), Hash(B),penc(S,cat(Hash(T),Hash(B)), enc(L,B)
Applications