Security Protocols: Analysis and Verification - PowerPoint PPT Presentation

1 / 56
About This Presentation
Title:

Security Protocols: Analysis and Verification

Description:

Security Protocols: Analysis and Verification Problems in Security Protocol Design Colloquium on Risk and Security of the Internet and Systems – PowerPoint PPT presentation

Number of Views:154
Avg rating:3.0/5.0
Slides: 57
Provided by: CUE49
Category:

less

Transcript and Presenter's Notes

Title: 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_at_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.or
    g
  • Protocols that we understand, but their
    verification is still difficult
  • Problems for which there is still no well-defined
    solution

12
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
The Philosopher-translator-secretary Architecture
Based on A. S. Tanenbaum
Philosopher
Philosopher
Pure ontology
Pure Ontology
R/W
R/W
Urdu
French
French
German
Translator
Translator
Translator
Fax
Secretary
Secretary
Secretary
Secretary
  • 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.

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

Layers
17
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
Reasoning about Protocols standard ModelD-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
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
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
Statenat, Natext (fresh), Nbtext init State
0 knowledge(A) inv(Ka), Ka, Kb, ki
transition 1. State 0 /\ RCV(start)
gt State'2 /\ SND(Na'.AKb)
/\ witness(A,B,na,Na') 2. State 2 /\
RCV(Na.Nb'Ka) gt State'4 /\ SND(Nb'Kb)
/\ request(A,B,nb,Nb')
/\ secret(Na,B) end role
  • role Basic_Role () def
  • owns ? T
  • local e
  • init Init
  • accepts Accept
  • transition
  • event1 ? action1
  • event2 ? action2
  • end role

23
Composed Roles Parallel Composition
Pattern
Example
role Kerberos (..) composition Client /\
Authn_Server /\ TGS /\ Server end role
  • role Par_Role ()
  • def
  • owns ?T
  • local e
  • init Init
  • accepts Accept
  • composition
  • A ? B
  • end role

24
Composed Roles Sequential Composition
General Pattern
Example
  • role Seq_Role ()
  • def
  • owns ?T
  • local e
  • init Init
  • accepts Accept
  • A B
  • end role

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 cant solve or prove
2
26
Sources of new Complexity
  • Complex Inter-layer Relation
  • Groups
  • Example Broadcast Streaming
  • Mission Impossible
  • Better-than-nothing security
  • Dynamic and continuously evolving systems
  • Service-oriented computing
  • Web Services

New ProblemAreas
27
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
Inter-protocol, Inter-Layer DependenciesExample
SIP
29
Inter-Layer dependencies Embedded
ProtocolsExample Geopriv
30
Broadcast Streaming
  • The final game of the world championship
  • Millions of users, worldwide
  • But not all users have subscribed to this one
    transmission
  • Uni-directional Channels
  • Change of Keys each 20 Secs
  • Broadcast of Keys?

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

32
One WS View (Open Grid)
Layers
33
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
34
Web Services One Possible Scenario
Retailer
Supplier
Main Web Server
Proxy Application
?
Security must be a function of the business model
WS Use
35
Web Services One Architechture
Users
Portal (Presentation)
WServers
DBs
Single-Sign On, Trust Federation Authn, Authz,
Account, Audit Delegation Business Process vs.
Security Policies
Challenges
WebServ
36
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?

37
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
  • 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

38
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

39
Protocols we can not design
3
40
Where we do have Problems
Current (Future)ProblemAreas
  1. Configuration, Operation
  2. Global Routing and keying
  3. Policies for all purposes
  4. E2E QoS and Signaling
  5. Local routing and keying
  6. Homeland Security
  7. Trustworthiness

New ProblemAreas
41
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 dont know what certificates areidentities
    arent checked
  • NASA.COM or NASA.GOV?
  • MICROSOFT.COM or MICROS?FT.COM? (Cyrillic O)

42
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 dont know what certificates are,
    certificates real-world identities arent
    checked
  • Who is Dow, Jones? Who owns www.wsj.com?
  • NASA.COM or NASA.GOV? MICROSOFT.COM or
    MICROS?FT.COM? (Cyrillic O)

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

44
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

45
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

46
E2E Signaling
47
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?

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

49
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

50
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
51
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?
52
Trustworthiness
  • Trustworthiness Measuring and proving
  • Trusted Computing
  • How can one machine prove to another one (say
    both in a home environment)that one will respect
    the policies installed in the other?
  • Reputation and Risk Management

Trojans?
Trojans?
Rendering Agent
Rights Object
Operating System Drivers
53
Conclusions
54
Security Future
  • Complex trust assumptions and guarantees
  • Policies everywhere, Ownership
  • Finer granularity of rights
  • Devices many, embedded, ubiquitous
  • Which keys are on the device?
  • Stolen Devices
  • Untrusted Users, Tamper Resistance
  • May I trust my own device? Shared devices?
  • Viruses and Trojan Horses
  • May I trust someone elses device/platform/service
    ?
  • Composition
  • Online Composing Security Services
  • Policies everywhere, Ownership

55
Security Future
  • Security Goals non-repudiation, secrecy,
    integrity, qualified signatures with user
    interaction, service exposure limits
  • Security Mechanisms encryption, key agreement,
    redundancy, trust management, online
    verification of the integrity of services or
    platforms, self-healing and immunity techniques,
    resilience

56
Conclusions, again
  • Specification Languages and Logics for emerging
    security standards
  • Too specific, lack abstraction level for business
  • Stakeholder should define sec goals at
    orchestration or business flow level
  • And attacker model
  • Automatically derive the low-level security
    mechanisms (or proof)
  • Today services and applications are considered
    secure
  • because they use security mechanisms and
    protocols
  • But this is dangerous
  • Need a logic to reason about the security
    provided by resources and their interaction
  • Using special channels
  • Calling special servers (for attestation, signed
    timestamps, etc.).
  • Decomposing and enforcing Global security policies

57
Conclusions, again
  • New security topics
  • Service-oriented computing
  • dynamic and continuously evolving.
  • Integration of trusted platforms
  • Self-healing and immunity techniques
  • Exchange of emergency information, lawful
    interception, filtering for critical
    infrastructure security
Write a Comment
User Comments (0)
About PowerShow.com