Security Protocols: Analysis and Verification

1. Security Protocols: Analysis and Verification Problems in Security Protocol Design Colloquium on Risk and Security of the Internet and Systems  CRiSIS 2005, October 2005 Jorge.Cuellar@siemens.com

2. Questions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? • Where are the issues? • Complexity of system? • Language? Modeling? • Abstraction layer? • Compositionality? • How much of the security landscape can be addressed today by FM?

3. Conclusions • How far is verification of security protocols and systems? • Impact? Increasing, but still minor

4. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? Quite a bit: we understand better the protocol, the assumptions, the possible extensions, variants of the protocol

5. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? Yes, still very many

6. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? • Where are the issues? • Complexity of system? Yes

7. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? • Where are the issues? • Complexity of system? • Language? Modeling? Yes

8. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? • Where are the issues? • Complexity of system? • Language? Modeling? • Abstraction layer? Yes

9. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? • Where are the issues? • Complexity of system? • Language? Modeling? • Abstraction layer? • Compositionality? Yes

10. Conclusions • How far is verification of security protocols and systems? • Impact? • What do we learn from verification? • Are there protocols that we understand, but we do not know how to tackle? • Where are the issues? • Complexity of system? • Language? Modeling? • Abstraction layer? • Compositionality? • How much of the security landscape can be addressed today by FM? Not too much

11. Three Classes of Security Problems • Protocols that are able to model and to verify • See AVISPA (Automated Verification of Internet Security Protocols and Applications). FET Open. IST-2001-39252 snd BWW Project 02.0431, Jan 1, 2003 – June 30, 2005 http://www.avispa-project.org • Protocols that we understand, but their verification is still difficult • Problems for which there is still no well-defined solution

12. OMA WS-I SAML ID-FF 1.1 LECP WS-Sec Oasis LAP Subscribe xml Encryption Search Register xml Signature UDDI W3C WSDL SOAP xml Namespaces + Information Set xml Schema html Envelope (MIME ) IETF HTTP UDP TCP IP IEEE 802.11 GSM UMTS 3GPP Context: Standardisation Committees They still make many design errors Layers

13. Context: Security Today Mostly Network Security • 2 trusted devices communicate over not trusted networks • Who is this user? server? • Trust: Does he keep his keys secure? • What is he allowed to do? • Is this user known to a T3P? • Is the trusted 3rd party behaving correctly? Security Goals: non-repudiation, secrecy, integrity Security Mechanisms: encryption, key agreement

14. The End-to-End Paradigm Protocols we can prove 1

15. Philosophers (L4) discuss using pure ontology R/W (L3), Translators (L2), Secretaries (L1), Intermediaries Philosopher sends “theories” to peer. Each protocol is independent of the other ones. The Translators can switch from German to say, Finnish. Secretaries can switch from fax to e-mail or telephone without even informing the other layers. Each process may add some information intended only for its peer. Courier Courier The Philosopher-translator-secretary Architecture Based on A. S. Tanenbaum Philosopher Philosopher Pure ontology Pure Ontology R/W R/W Urdu French German French Translator Translator “Translator” Fax Secretary Secretary Secretary Secretary Layers

16. May study the layers almost independently Courier Courier The Philosopher-translator-secretary Architecture Based on A. S. Tanenbaum Philosopher Philosopher Pure ontology Pure Ontology R/W R/W Urdu French German French Translator Translator “Translator” Fax Secretary Secretary Secretary Secretary Layers

17. Application SET Middleware DNS,PKI DNS,PKI OCSP tcp / udp tcp / udp Transport Layer TLS ip ip Network Layer IPsec-IKE Ethernet Ethernet Data Link Layer WLAN-Wep Physical Layer Host Access Point or Gateway Life is OK: IETF View Layers

18. Where life is OK Areas where we can prove correctness (AVISPA Project) • Infrastructure (DHCP, DNS, BGP, stime) • Network Access (WLAN, pana) • Mobility (Mobile IP, UMTS-AKA, seamoby) • VoIP, messaging, presence (SIP, ITU-T H530, impp, simple) • Internet Security (IKE (IPsec Key agreement), TLS, Kerberos, EAP, OTP, Sacred, ssh, telnet,...) • Privacy (Geopriv) • AAA (DIAMETER), Identity Management, Single Sign On (Liberty Alliance) • Security for QoS, etc. (RSVP, NSIS) • Broadcast/Multicast Authentication (TESLA) • E-Commerce (Payment) AVISPA covers most of the standard IETF Security Protocols (plus some current ones, under discussion)

19. A, nI, KeyA, KeyB Intruder Knowledge {A, nA} KeyB {A, nI} KeyB trustworthy device trustworthy device channel: data + Control msgs Reasoning about Protocols — standard Model:D-Y Intruder D-Y Intruder may: • Intercept / emit messages • Decrypt / encrypt with known key (Black-box perfect crypto) • Split / form messages • Use public information • Generate fresh data Assume: perfect cryptography

20. {A, nA} KeyI {A, nA} KeyB {nA, nB} KeyA {nA, nB} KeyA {nB} KeyI {nB} KeyB Example: NS Public-Key (1978) {A, nA} KeyB {nA, nB} KeyA {nB} KeyB • B believes he is speaking with A!

21. The AVISPA Specification Language HLPSL • Relatively high degree of abrstaction • Rather expressive: • Crypto-Operatorion: Encryption, Signature, Hashes, Nonces • Algebraic Properties (e.g. exp und xor) • Control flow: branching on conditions and loops • Intruder knowledge explicitely definable • Modularity: Composition of Roles in local environments • Security goals: Secrecy, weak and strong authentication, temporal logic properties • Reference semantic very close to TLAMay be interpreted as a set of rewrite rules (search backwards with unification) • Type system with complex Data types • Easy to learn and use ( Programming Language)

22. role Basic_Role (…)def= owns {θ: Θ} local {ε} init Init accepts Accept transition event1  action1 event2  action2 … end role Basic Roles General Pattern Initiator Role in NSPK role Alice (A, B: agent, Ka, Kb: public_key, SND, RCV: channel (dy)) played_by A def= local State:nat, Na:text (fresh), Nb:text init State = 0 knowledge(A) = {inv(Ka), Ka, Kb, ki} transition 1. State =0 /\ RCV(start) =|> State'=2 /\ SND({Na'.A}Kb) /\ witness(A,B,na,Na') 2. State =2 /\ RCV({Na.Nb'}Ka) =|> State'=4 /\ SND({Nb'}Kb) /\ request(A,B,nb,Nb') /\ secret(Na,B) end role

23. role Par_Role (…) def= owns {θ:Θ} local {ε} init Init accepts Accept composition A  B end role Composed Roles: Parallel Composition Pattern Example role Kerberos (..) composition Client /\ Authn_Server /\ TGS /\ Server end role

24. role Seq_Role (…) def= owns {θ:Θ} local {ε} init Init accepts Accept A ; B end role Composed Roles: Sequential Composition General Pattern Example role Alice (..) establish_TLS_Tunnel(server_ authn_only); present_credentials; main_protocol(request, response) end role

25. New Paradigms Problems/Protocols we think we understand but we can’t solve or prove 2

26. Sources of new Complexity New ProblemAreas • Complex Inter-layer Relation • Groups Example: Broadcast Streaming • Mission Impossible: Better-than-nothing security • Dynamic and continuously evolving systems Service-oriented computing Web Services

27. Untrusted Application A Peer Untrusted Network Layers and dependencies • IETF provides secure channels (IPsec, TLS, ..), OMA uses them • The high-level spec is built upon “secure channel assumption” • If a device is not trusted (or the user), how to make keys available only to „application A“ and not to untrusted layers? • How to prove that I am „application A“? • Identities • user name, IP address, MAC, TCP port, ... What is “A”, “Alice”, “ID_A”?

28. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP Signup, Find buddies IM, call On reset Sign-out, transfer On startup Leave Find Join REG, INVITE, MESSAGE Peer found/ Detect NAT Multicast REG REG Inter-protocol, Inter-Layer DependenciesExample: SIP

29. Authorization Framework Location Configuration Basic Rule set Extended Rule set Common Policy DHCPOption Geopriv Policy Conference Policy PIDF-LO Presence Policy Using Protocols SIP/SIMPLE RADIUS/Diameter DHCP Application Domain and Use Cases Application Domain and Use Cases Location based Network Access Authorization, Taxation and Billing Conferencing Location based Services, Presence and IM Emergency Calls and Location based Call Routing Inter-Layer dependencies: Embedded Protocols:Example: Geopriv

30. Better-than-nothing, less than perfect security • Conditional Security • over the air • “safer” routes • Many types of DoS attacks • flooding, bombing, starving, disrupting • Layered Properties: • if attacker ... then ..., if attacker ... then ...

31. AppServer Platform (OS) Application security Exploiters security security (on top of app server) ... Security services AuthnService AttributeService AuthzService AuditService (TBD) Federation layer WS-Federation WS-SecureConversation WS-Authorization Policy layer WS-Policy WS-Trust WS-Privacy ... xenc: ds: Message Security SecurityToken EncryptedData Signature ... Web services WSDL SOAP WS-Routing WS*L standards ... XML security XML XML Assertion XKMS XACML standards Signature Encryption Language ... Protocol layer IIOP HTTP JMS CSIv2 (MQ) https security ... Platform resource NT Solaris Linux AIX security One WS View (Open Grid) Layers

32. Another WS Security View WS-Privacy WS-Federation WS-Authorization Liberty Alliance XrML WS-Policy-* WS-Secure Conversation XACML WS-Trust SAML WS-Security standardized In progress SOAP Foundation proposed promised Layers

33. XKMS Server SAML Authorities User Web Services: One Possible Scenario Retailer Supplier Main Web Server Proxy Application ? Security must be a function of the business model WS Use

34. Web Services: One “Architechture” DBs WServers Portal (Presentation) Users Challenges: Single-Sign On, Trust Federation Authn, Authz, Account, Audit Delegation Business Process vs. Security Policies WebServ

35. Security Services and Composition • How to model a generic Identity Provider, a secure mail provider, a secure time-stamp server? • How to reason about secure services composition?

36. Some Protocols BPEL BTP (OASIS) ebXML BP (OASIS/CEFACT) WSBPEL (OASIS) WS-Chor (W3C) WS-CAF (OASIS) ASAP (OASIS) WSDM (OASIS) WS-RF (OASIS) WS-Notification (OASIS) Private specs for Transactions Choreography Notification Eventing Management Web Services: Orchestration and Management Higher-level security services  more application-layer access via gateways, proxies, … Difficult semantics of orchestration languages and of business models

37. A B c PW A ―• B A ――> B IdP c A • ―• B How to cope with the complexity? • Many types of channels, weaker than Dolev-Yao: • Over the air • Authentic Channels • Confidential Channels • Proof Channels (Non-Repudiation of reception / send) • Abstraction Layers • One sub-protocol provides a secure channel, the other one uses it • The channel mutation problem • Exercise: SSO over http-s:

38. Protocols we can not design 3

39. Where we do have Problems Current (+Future)ProblemAreas • Configuration, Operation • Global Routing and keying • Policies for all purposes • E2E QoS and Signaling • Local routing and keying • Homeland Security • Trustworthiness New ProblemAreas

40. Deployment, Configuration, Operation, User Interface • Encryption and authentication algo are ±ok • Activating these mechanisms • Key management (PKI,...): weak • Secure configurations • Epidemics, cascades, flexible policies • User interface problem • Users don’t know what certificates areidentities aren’t checked • NASA.COM or NASA.GOV? • MICROSOFT.COM or MICROSОFT.COM? (Cyrillic “O”)

41. Deployment, Configuration, Operation, User Interface • Encryption and authentication algo are ±ok • Activating these mechanisms • Key management (PKI,...): weak • Keys are a single point of failure, Key revocation • Secure configurations • Epidemics, cascades, flexible policies • A worm may infect all vulnerable servers in Internet in less than a minute • User interface problem • Users don’t know what certificates are, certificates’ real-world identities aren’t checked • Who is Dow, Jones? Who owns www.wsj.com? • NASA.COM or NASA.GOV? MICROSOFT.COM or MICROSОFT.COM? (Cyrillic “O”)

42. Global Routing, Keying • Internet as a Global village? • in a village, you know your neighbours • BGP-4 • Secure Diffusion of Routing Information

43. Global Routing: Address-space ownership Example: Bombing HoA • In MIPv6 the MN has a default address, to which data will be sent when its current location is unknown. • Attacker claims to have a HoA in the target network. It starts downloading a data stream and either sends a request to delete the binding cache entry or allows it to expire. This redirects the data stream to the false HoA . • Target can do nothing to prevent the attack. • Attacker needs to find a CN that is willing to send data streams to unauthenticated recipients. • Many popular web sites provide such streams

44. Policies for everything • DOS, security attacks  permissions-based communications • only allow modest rates without asking • effectively, back to circuit-switched • Forcing homogeneity on users is useless • Everyone has his own preferences • User control of communications • from anywhere, anytime, any media to where appropriate, my time, my media • fix spam • keep cell phone from ringing in the concert • Meta-policies • Policy refinement (logical implication) • Modularity, Conjunction, Negation, Distribution, Resolution

45. QoS QoS NAT/FW E2E Signaling

46. Local Routing and Keying • Myriad of Wireless small devices embedded in physical objects and other components • Small and invisible, low-cost, Ad-hoc Routing • Wireless communication • Radio transmitter + receiver, Atom-clocks, etc. in millimetres • wearables • media players • sensors • cameras • MEMS (Micro-electro-mechanical systems) • Sensor Networks • Active Badges and Tags (RFID) • Hierarchical key management? (Personal CAs) • Trust? • Privacy?

47. Inter-protocol, Inter-Layer Dependencies • Create Secure Channel at one layer • Use it to generate a secure channel at a different layer • GBA-U • On the other hand: decoupling Application Middleware

48. Homeland Security • Security for Critical Infrastructures • Lots of technologies involved • New and more expensive Vulnerabilities • Big events (Olympia), Large Projects (E-health card) • SCADA: 24/7 availability • Many of the usual security mechanisms do not apply • Password management • Patches • Protocols, policies for critical situations • Cascade Control • Congestion control in Emergency

49. Trust modelling challenge: Example: DRM User Terminal Content Provider Encrypted Content, Rights Object DRM Agent Renders the Content {C} CEK Operating System HW drivers {R, CEK} DK Manufacturer Terminal ID, Keys Secure Container

50. The Problem Viruses Untrusted SW User Terminal Content Provider Encrypted Content, Rights Object Trojan Horses DRM Agent Renders the Content Proof Operating System HW drivers Manufacturer Terminal ID, Keys Secure Container How can T prove to CP that he will use C only according to R?