a logic of secure systems with tunable adversary models
Post on 08-Feb-2016
37 Views
Preview:
DESCRIPTION
TRANSCRIPT
A Logic of Secure Systems with Tunable Adversary Models
Jason FranklinWith Anupam Datta, Deepak Garg, Dilsun Kaynar
CyLab, Carnegie Mellon University
Motivation: Secure Access to Financial Data
2
Network
Goal: An end-to-end trusted path in presence of local and
network adversaries
Secure System DesignsSecurity Property
System maintains integrity of OS and web server code.
Secure System
BIOS
OS
Web Server
Adversary
Malicious Thread
Communication between frames remains
confidential.
Malicious Frame & ServerMalicious Virtual Machine
The VMM maintains the confidentiality and integrity
of data stored in honest VMs.
Logic-based Analysis of System Security
Security Property
Secure System
Formal Model of Adversary Analysis Engine
Proof of security
property or identify attack
A. Datta, J. Franklin, D. Garg, D. Kaynar, A Logic of Secure Systems and its Application to Trusted
Computing,Oakland’09
Adversary defined by a set of capabilities
MethodSecurity PropertySecure System
Adversary Model
Modeled as a set of programs in a concurrent programming language containing primitives relevant to secure systems
Cryptography, network communication, shared memory, access control, machine resets,
dynamic code loading
Specified as logical formulas in the Logic of Secure Systems (LS2)
Any set of programs running concurrently with
the systemAnalysis Engine
Sound proof system for LS2
Adversary ModelAdversary capabilities:
Local process on a machineE.g., change unprotected code and data, steal secrets, reset
machines In general, constrained only by system interfaces
Network adversary:E.g., create, read, delete, inject messagesMore later in Arnab Roy’s talk
These capabilities enable many common
attacks: Network Protocol Attacks: Freshness, MITMLocal Systems Attacks: TOCTTOU and other race
conditions, violations of code integrity and data confidentiality and integrity violation
Combinations of network and system attacks, e.g., web attacks
ApplicationCase study of Trusted Computing Platform
TCG specifications are industry and ISO/IEC standardOver 100 million deployments Applications include Microsoft’s BitLocker and HP’s
ProtectToolsFormal model of parts of the TPM co-processorFirst logical security proofs of two attestation
protocols Results of analysis:
Previously unknown incompatibility between protocolsCannot be used together without additional protection
2 new weaknessesPreviously known TOCTTOU attacks
[GCB+(Oakland’06),SPD(Oakland’05)]Principled source code audit
TCG Remote Attestation
Describe your software stack!
Remote Verifier
Client
Why should the client’s answer be trusted?
Trusted Platform Module (TPM)
PCRRemoteVerifier
Client
Trusted Computing Platform Components
BOL
Co-processor for
cryptographic operations
Protected private key
(AIK)
Append only log;
Set to BOL on reset
Industry standard developed by Trusted Computing Group
Check
APP
Trusted Platform Module (TPM)
Dynamic PCR
Client
Check
Dynamic Root of Trust for Measurement (DRTM)
LL
PBOL
……latelaunch
PNonce, EOL
Nonce
Isolated Environmen
t
EOL
RemoteVerifier
Security Skeleton of DRTM in LS2
Remote Verifier
Operating Sys.
Co-processor
Late Launch
Protected Program
Abstraction: Security skeleton only models security relevant operations
Challenge: Dynamic Code Loading
Remote Verifier
Operating Sys.
Co-processor
Late Launch
Protected Program
Abstraction: Security skeleton only models security relevant operations
Typically programs proved correct assuming code known at time of invocation
Reasoning about security of dynamically loaded unknown code requires separate technique to identify code of P
What is P?
Proof of DRTM Security Property
13
tN tC tE
NonceGenerated
Jump P Eval f VerifierFinishes
te
APP
Trusted Platform Module (TPM)
Dynamic PCR
RemoteVerifier
Client
Check
Refining Trust Requirements between Systems
LL
PBOL
……latelaunch
PNonce, EOL
Nonce
Isolated Environmen
t
EOL
• P is provided by application (APP)• P has full access to the machine• What if P is malicious?
BLOS
APP
Trusted Platform Module (TPM)
PCRBIOS RemoteVerifier
Client
Signature
Check
Backwards incompatibility
BLOSAPP H(APP)
H(OS)H(BL)BOL
SLBP
Isolated Environmen
t
H(APP1)H(APP2)
Verifier believes
(incorrectly) that APP1 was
loaded on Client
Insecure composition of DRTM and SRTM (not modular)
Principled Source Code Auditing
int slb_dowork(unsigned long params) { unsigned char buffer[34],
buffer2[34]; if(slb_prepare_tpm() < 0) { goto
tpm_error; }
pal_enter((void *)params); memset(buffer2, 0x00, 20); /* Extend("bottom") */ slb_TPM_Extend(buffer, 17, buffer2);
tpm_error: build_page_tables(); return 0; }
Toward secure refinement from design to code
•Correspondence between system design and implementation•Small TCB aids correspondence check (Flicker ~ 250 LOC) + abstractions
In-progress work…Towards an interface-based theory of
system securityAdversary
Trust Boundary
Hardware
Operating System
Tunable Adversary Models
LS^2 has fixed adversaryLocal concurrently-executing malicious thread
Can we extend LS^2 with tunable adversaries?Consider adversary that is Constrained to System
Interfaces (CSI) Adversary can interleave interface calls, combine outputs,
compose interfaces to produce new interfacesDRTM-adversary has interface <skinit, extend, …,write>
AdversaryTrust Boundary
Hardware
Operating System
Qualitative Comparison of SecurityComparing Adversary Models: Given two S-system interface-specified
adversaries S-Adv1 and S-Adv2 is S-Adv2 more powerful than S-Adv1?
S-Adv1Trust Boundary
Hardware
Operating System
S-Adv2
Other Scientific QuestionsComparing Systems: A system S1 is at least as secure as a
system S2 … if S2-Adv S2 is secure S1-Adv S1 is
secure
Modularity: If system S1 is secure against adversary
S1-Adv and system S2 is secure against adversary S2-Adv, how can we reason modularly about the security of system S1||S2 against adversary S1-Adv||S2-Adv?
ConclusionA logic for reasoning about secure systemsAnalysis of trusted computing attestation protocols
Formal model of parts of the TPM co-processorFirst logical security proofs of two attestation protocols (SRTM
and DRTM)Analysis identifies:
Previously known TOCTTOU attacks on SRTM [GCB+(Oakland’06),SPD(Oakland’05)]
Previously unknown incompatibility between SRTM and DRTM(Cannot be used together without additional protection)
In-progress work includes interface-based modeling and analysis
ThemesAdversary models, modular verification, secure
refinement, design for verification
Work Related to LS2
Work on network protocol analysisBAN, …, Protocol Composition Logic (PCL)
Inspiration for LS2, limited to protocols onlyLS2 adds a model of local computation and local adversary
Work on program correctness (no adversaries)Concurrent Separation Logic
Synchronization through locks is similarHigher-order extensions of Hoare Logic
Code being called has to be known in advanceTemporal, dynamic logic
Similar goals, different formal treatmentFormal analysis of Trusted Computing Platforms
Primarily using model checking
top related