security protocols: analysis and verification

Automated Validation of Internet Security Protocols and ApplicationsShared cost RTD (FET open) project IST-2001-39252

C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y

Information & Communications

Security

Security Protocols: Analysis and Verification

Problems in Security Protocol Design

Colloquium on Risk and Security of the Internet and Systems

CRiSIS 2005, October 2005

[email protected]

© Siemens AG, CT IC 3, J. Cuellar Oct 2005

C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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?


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?

Increasing, but still minor


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?


Quite a bit: we understand better the protocol, the assumptions, the possible extensions, variants of the protocol


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?



Yes, still very many


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?





Yes


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?






Yes


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?







Yes


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?








Yes


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


• Impact?








• How much of the security landscape can be addressed today by FM?

Not too much


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Context: Standardisation Committees

Layers

802.11GSM

OMA

IEEE

IP

UDPTCP

HTTP Envelope (MIME )

html

WS-I

xml Namespaces+ Information Set

SOAP

xml Signature

WS-Sec

SAML

xml Encryption

WSDL

xml Schema

UDDI

RegisterSearch

Subscribe

3GPP

IETF

W3C

OasisID-FF 1.1LECP

LAP

UMTS

They still make many design errors


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

The End-to-End Paradigm

Protocols we can prove

1


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

The Philosopher-translator-secretary Architecture

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

Based on A. S. Tanenbaum

Layers

R/W

Translator

Secretary

Translator

Secretary

R/W

“Translator”

Secretary

Urdu FrenchFrenchGerman

Courier FaxCourierSecretary

Philosopher Philosopher

Pure ontology Pure Ontology


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

The Philosopher-translator-secretary Architecture

• May study the layers almost independently

Based on A. S. Tanenbaum

Layers

R/W

Translator

Secretary

Translator

Secretary

R/W

“Translator”

Secretary

Urdu FrenchFrenchGerman

Courier FaxCourierSecretary

Philosopher Philosopher

Pure ontology Pure Ontology


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Life is OK: IETF View

Access Pointor Gateway

DNS,PKI

tcp /udp

ip

Ethernet

DNS,PKI

tcp /udp

ip

Ethernet

Host

Middleware

TransportLayer

NetworkLayer

Data LinkLayer

PhysicalLayer

WLAN-Wep

IPsec-IKE

TLS

OCSP

SETApplication

Layers


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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)


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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

channel: data + Control msgs

trustworthydevice

trustworthydevice

{A, nA} KeyB {A, nI} KeyB

A, nI, KeyA, KeyB

Intruder Knowledge


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Example: NS Public-Key (1978)

• B believes he is speaking with A!

{A, nA} KeyB

{nA, nB} KeyA

{nB} KeyB

{A, nA} KeyI

{nA, nB} KeyA

{nB} KeyI{nB} KeyB

{A, nA} KeyB

{nA, nB} KeyA


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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)


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Basic Roles

role Basic_Role (…) def=

owns {θ: Θ}

local {ε}

init Init

accepts Accept

transition

event1 action1

event2 action2

…

end role

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

General Pattern Initiator Role in NSPK


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Composed Roles: Parallel Composition

role Par_Role (…)

def=

owns {θ:Θ}

local {ε}

init Init

accepts Accept

composition

A B

end role

Pattern Example

role Kerberos (..) composition Client /\ Authn_Server /\ TGS /\ Serverend role


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Composed Roles: Sequential Composition

role Seq_Role (…)

def=

owns {θ:Θ}

local {ε}

init Init

accepts Accept

A ; B

end role

General Pattern Example

role Alice (..) establish_TLS_Tunnel(server_ authn_only); present_credentials; main_protocol(request, response)end role


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

New Paradigms

Problems/Protocols we think

we understand

but we can’t solve or prove

2


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Sources of new Complexity

1. Complex Inter-layer Relation

2. Groups

Example: Broadcast Streaming

3. Mission Impossible:

Better-than-nothing security

4. Dynamic and continuously evolving systems

Service-oriented computing

Web Services

New ProblemAreas


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

• 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”?

Network Layers and dependencies

Application A

Untrusted

PeerUntrusted


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Inter-protocol, Inter-Layer DependenciesExample: SIP

User interface (buddy list, etc.)

SIPICE RTP/RTCP

Codecs

Audio devicesDHT (Chord)

On startup

Discover

User location

Multicast REGPeer found/Detect NAT

REGREG, INVITE,MESSAGE

Signup,Find buddies

JoinFind

Leave

On resetSign-out,transfer

IM,call


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Authorization Framework

Basic Rule set

Extended Rule set

Application Domain and Use Cases

SIP/SIMPLE RADIUS/Diameter DHCP

Location based Services, Presence

and IM

Emergency Callsand Location based Call

Routing

Location based Network Access Authorization, Taxation and

Billing

Common

Policy

Using Protocols

Location Configurati

on

Conferencing

Application Domain and Use Cases

DHCPOption

Geopriv Policy

Presence PolicyPIDF-LO

Conference Policy

Inter-Layer dependencies: Embedded Protocols:Example: Geopriv


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

One WS View (Open Grid)

HTTPhttps

IIOPCSIv2

JMS(MQ)...Protocol layer

security

AttributeServiceAuthnService AuthzService AuditService...Security services (TBD)

AppServer security

Platform (OS) security

Application security(on top of app server)Exploiters

XML securitystandards

XML Signature

XML Encryption XACMLXKMSAssertion

Language ...

Message Security ds:Signature

xenc:EncryptedData SecurityToken...

Policy layer WS-Policy WS-Trust WS-Privacy

WS-Federation WS-SecureConversation WS-AuthorizationFederation layer

Web servicesstandards

WSDL SOAP WS*L... WS-Routing

Platform resource security

NT Linux AIXSolaris ...Layers


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Another WS Security View

proposedproposedSOAP FoundationSOAP Foundation

WS-SecurityWS-Security

WS-PrivacyWS-Privacy

WS-SecureWS-SecureConversationConversation

WS-FederationWS-FederationWS-AuthorizationWS-Authorization

In progressIn progress

promisedpromised

SAMLSAML

Liberty AllianceLiberty Alliance

WS-TrustWS-Trust

WS-Policy-*WS-Policy-*XACMLXACML

standardizedstandardized

XrMLXrML

Layers


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Web Services: One Possible Scenario

Proxy Application

Main Web Server

Retailer

WS Use

Supplier

User

XKMS Server

SAML Authorities

?

Security must be a function of the business model


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Web Services: One “Architechture”

WebServ

Users Portal

(Presentation)

WServers DBs

Single-Sign On, Trust FederationAuthn, Authz, Account, Audit DelegationBusiness Process vs. Security Policies

Challenges:


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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?


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Web Services: Orchestration and Management

• 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

Higher-level security services more application-layer access via gateways, proxies, …

Difficult semantics of orchestration languages and of business models


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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:

A • ―• Bc

A ―• Bc

A ――> BPW

BA

IdP


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Protocols we can not design

3


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Where we do have Problems

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

Current (+Future)Problem

Areas

New ProblemAreas


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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”)


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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”)


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Global Routing, Keying

• Internet as a Global village?

• in a village, you know your neighbours

• BGP-4

• Secure Diffusion of Routing Information


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

E2E Signaling

NAT/FW

QoS QoS


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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?


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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

Middleware

Application


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Encrypted Content,

Rights Object

Terminal ID,KeysSecure Container

DRM Agent Renders the Content

Operating SystemHW drivers

User Terminal Content Provider

Manufacturer

Trust modelling challenge: Example: DRM

{C} CEK

{R, CEK} DK


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Encrypted Content,

Rights Object

VirusesUntrusted SW

Terminal ID,KeysSecure Container

Trojan Horses

User Terminal Content Provider

Manufacturer

The Problem

DRM Agent Renders the Content

Operating SystemHW drivers

How can T prove to CP that he will use C only according to R?

Proof


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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

Rights Object

Rendering Agent

Operating SystemDrivers

Trojans? Trojans?

ProofProof


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

Conclusions


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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 else’s device/platform/service?

• Composition

• Online Composing Security Services

• Policies everywhere, Ownership


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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


C

O R

P O

R A

T E

T

E C

H N

O L

O G

Y


Security

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

security protocols: analysis and verification

Documents

verification problems

security landscape

protocol siemens ag

minor siemens ag

complexity of system

abstraction layer

possible extensions

snd bww project