Modeling and Analysis of Networked Secure Systems with Application to Trusted Computing

Modeling and Analysis of Networked Secure Systems with Application to Trusted Computing Jason Franklin Joint work with Deepak Garg, Dilsun Kaynar, and Anupam Datta

Motivation • Despite progress in cryptography and security protocols, designing securesystemsremainsdifficult • Network protocols and cryptography rely on secure system assumption • Problem: Attackers violate secure system assumption by exploiting system design flaws • Solution: Prove security of system designs

Motivating Example Client System Network Server System

Trusted Computing • Question: How do we trust remote servers? • Proposed Solution: Ask servers what programs they are running? • Server attests to (vouches for) its running software…

Details of Proposed Solution Since I last rebooted, I’ve run 0: Operating System 1: Web Server 2: Shopping Cart Server System and Network Protocol Analysis I’ll ask what programs they have run! How do I know if I can trust that server? Hey server! What code have you run? I trust those programs to protect my data! Network Protocol Analysis Network Client System Server System Request Reply

In this talk… • Describe Logic of Secure Systems (LS^2) • Modeling system designs • Analysis of system designs • Analyze trusted computing protocol • Limitations, work in progress, and conclusion

Modeling Protocols as Programs Since I last rebooted, I’ve run 0: Operating System 1: Web Server 2: Shopping Cart Server Hey server! What code have you run? I trust those programs to protect my data! Network Client System Server System request Reply Client ≡ request := read question; send request; reply := receive; match /reply/trusted/; Server ≡ r := receive; send reply;

Components of Model Key: Existing Added Memory Memory Protection Explicit Time Control Flow Hardware Resets Trusted Computing Threads Network Comm. Hash Encryption Decryption Sign/Verify

Modeling Details • Memory • Read and write named memory locations • Example: d := read Mem[x]; • Memory Protection • Exclusive write locks • Example: lock(Mem[x]); • Explicit time • Ordering events • Read at time TR, Write at time TW and TR < TW • Expressing invariants • Mem[x] contains value V during interval (TR,TW)

New Adversary Model I can generate messages if I know their components! I can remove, reorder, or replay messages. I’m a malicious local thread! I can write to any unprotected memory location! I can read any memory location! I collude with the network adversary! Network Client System Server System Standard Network Adversary

Overview of Protocol Analysis Modeling Analysis Client ≡ request := read question; send request; reply := receive; match /reply/trusted/; Suppose Client code executed then: Server is executing trusted programs

LS^2, what are you good for? • Describe Logic of Secure Systems (LS^2) • Analyze trusted computing protocol • Limitations, work in progress, and conclusion

Problems with Trusted Computing Protocol Since I last rebooted, I’ve run malicious code. Mwhahaha!!!! Hey server! What code have you run? I trust those programs to protect my data! Since I last rebooted, I’ve run linux. Really, I have! Network Client System Malicious Server System Reply request Client ≡ request := read question; send request; reply := receive; match /reply/trusted/; MALICIOUS_Server ≡ r := receive; send “linux”;

Solution: Trusted Coprocessor Server System Trusted Coprocessor Client System Network

Trusted Coprocessor • Trusted Computing • Augments platform with trusted co-processor • Coprocessor includes: • Crypto. Primitives • Keys • Append-only log Coprocessor … Log : A B Log.append(A); Log.append(B);

Server with Coprocessor Server System Booting ≡ 1. append log, os_code; os := read os_code; 2. call os; 3. append log, web_server_code; ws := read web_server_code; 4. call ws; Web Server 3. Append 4. Call OS 2. Call 1. Append Coprocessor … Log = os_code web_server_code

Coprocessor Vouching for Log Signer ≡ _ := receive; w := read log; s := sign w, K; send s … os_code ws_code Log = s := SIGN K, (os_code, ws_code) Client System Client_Receive ≡ s := receive; verify s, seq(os_code, ws_code), K

Protocol Analysis Modeling Analysis Client_Receive ≡ s := receive; verify s, seq(os_code, ws_code), K Suppose Client code executed then: Server is executing trusted programs

Trusted Computing Analysis • Suppose that clients’s thread executes code Client_Receive in time interval [Begin, End) then the following properties hold: Read Log @ TRead Verify Log @ TV Call to OS Code @ TOS Reset @ TR Begin End No Resets during TR to TRead

Server Reset Anyone See Security Vulnerability? • Reset attack possible after read of log Verification of Stale Data Read Log @ TRead Verify Log @ TV Client believes server can be trusted! Call to OS Code @ TOS Reset @ TR Begin End No Resets during TR to TRead

Adversaries Attack Assumptions • Assumptions: • Client is not running in coprocessor • Coprocessor does not reveal its private key • Coprocessor only executes Signer • Programs in memory are write locked

Up next… • Describe Logic of Secure Systems (LS^2) • Designed for modeling and analysis of system specifications • Use LS^2 to analyze trusted computing protocols • Specify trusted computing protocols • State security properties and security proof • Discuss implications and analysis of proof • Limitations, work in progress, and conclusion

Limitations and Work In Progress • Control flow and context sensitive analysis • Composition theorems for modular analysis of complex systems • Expanding access control policies • Analysis of other trusted computing protocols • Modeling layer diagrams User Level Programs Operating System Hardware Layer Diagram

Related Work • LS^2 is derived from Protocol Composition Logic [Datta05-07] • Related work on program correctness: • Concurrent separation logic [Brookes04] • Verification of concurrent systems [TLA, Lamport84, Owicki&Gries76]

Conclusion • LS^2 is logic for analysis of networked secure systems including local and network adversaries • LS^2 models abstract memory protections, time, hardware resets, and security primitives • Described formal analysis of trusted computing • Identified reset attack • Ongoing work seeks to expand scope of LS^2

Take Home Points • If you are designing secure systems: • LS^2 enables security analysis of system design before you implement • Avoids costly and embarrassing vulnerabilities • Clarifies security properties of design • Even if you are just using secure systems: • LS^2 can provide stronger guarantees about your security

Questions? • Theory of Secure Systems Project (ToSS) • http://www.cs.cmu.edu/~jfrankli/toss • Publications and Manuscripts: • D. Garg, J. Franklin, D. Kaynar, A. Datta. “Towards a Theory of Secure Systems” Cylab Technical Report, Feb. 2008. • D. Garg, J. Franklin, D. Kaynar, A. Datta. “A Logic for Reasoning about Networked Secure Systems.” Under submission to FCS ’08. • J. Franklin, D. Garg, D. Kaynar, A. Datta. “Modeling and Security Analysis of Trusted Computing.” In progress.

Modeling and Analysis of Networked Secure Systems with Application to Trusted Computing