Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open)...
-
date post
19-Dec-2015 -
Category
Documents
-
view
219 -
download
3
Transcript of Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open)...
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
© 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
Information & Communications
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?
© 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
Information & Communications
Security
Conclusions
• How far is verification of security protocols and systems?
• Impact?
Increasing, but still minor
© 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
Information & Communications
Security
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
© 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
Information & Communications
Security
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
© 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
Information & Communications
Security
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
© 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
Information & Communications
Security
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
© 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
Information & Communications
Security
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
© 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
Information & Communications
Security
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
© 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
Information & Communications
Security
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
Security
The End-to-End Paradigm
Protocols we can prove
1
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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)
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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)
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
Security
New Paradigms
Problems/Protocols we think
we understand
but we can’t solve or prove
2
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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 ...
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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:
© 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
Information & Communications
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?
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
Security
Protocols we can not design
3
© 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
Information & Communications
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
© 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
Information & Communications
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”)
© 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
Information & Communications
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”)
© 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
Information & Communications
Security
Global Routing, Keying
• Internet as a Global village?
• in a village, you know your neighbours
• BGP-4
• Secure Diffusion of Routing Information
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
Security
E2E Signaling
NAT/FW
QoS QoS
© 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
Information & Communications
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?
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
Security
Conclusions
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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
© 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
Information & Communications
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