Synthesis of Secure Adaptors

198 views

Published on

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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
198
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Synthesis of Secure Adaptors

  1. 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. 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. 3. Example: Stateful services Service a Service b Encoded in Crypto-CCS
  4. 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. 5. Example: Adaptor AdaptorService a Service b
  6. 6. Example: Adaptor AdaptorService a Service b
  7. 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. 8. Overview
  9. 9. Overview
  10. 10. Example: Incompatible services Service a Service b
  11. 11. Overview
  12. 12. Example: Incompatible services Service a Service b
  13. 13. Example: Incompatible services Service a Service b HOW: send! could match with either anonymous?, des?, pub_rsa? or priv_rsa?
  14. 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. 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. 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. 17. Adaptation contract Service a Service b Sec. Adaptation Contract anonymous!M^ < send?M public_key! < ... E0 VLTS
  18. 18. Adaptation contract Service a Service b Sec. Adaptation Contract anonymous!M^ < send?M public_key! < ... E0 VLTS
  19. 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. 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. 21. Overview
  22. 22. Interactions compliant with SACService a Service b Adaptor Sec. Adaptation Contract 1. anonymous!M^ < send?M 2. public_key! < 3. login!U^,E(K^,U^) <
  23. 23. Deadlock free synthesis AdaptorService a Service b SAC
  24. 24. Deadlock free synthesis AdaptorService a Service b SAC
  25. 25. Deadlock free synthesis AdaptorService a Service b SAC
  26. 26. Overview
  27. 27. Secrecy propertyService a Service b ● What do you want to protect? ● Which channels are subject to attack? ○ Restricted Dolev-Yao model ● Which information is public?
  28. 28. Secrecy propertyService 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. 29. Secrecy propertyService 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. 30. Partial model checkingService a Service b (thanks to partial model-checking)
  31. 31. Verification AdaptorService a Service b Attack
  32. 32. Refinement AdaptorService a Service b
  33. 33. Secure security adaptor AdaptorService a Service b SAC
  34. 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. 35. Thank you!Paper: http://bit.ly/JLAP12 -- Thesis: http://bit.ly/jamartin-thesis
  36. 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. 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. 38. Applications

×