Next Generation Secure Computing Base

1. Next Generation Secure Computing Base John Manferdelli jmanfer@microsoft.com Security Business Unit Microsoft Corporation

2. Network level Encryption IPsec Monitoring tools ACL VA tools Reporting tools SSL HSM Network IDS Air gap network Config and patch mgt Content screening VPN Encryption Network segmentation Firewall, Proxy server 2-factor authentication, one time password, digital signature Antivirus software Personal firewall The Problem Remote Edge Core data, IP, apps, “secrets” internet extranet • “Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench.” • Professor Gene Spafford Perdue CERIAS Corp network

3. Next Generation Secure Computing Base Defined • Microsoft’s Next-Generation Secure Computing Base (NGSCB) is a bad name for a new security technology for the Microsoft Windows platform • Uses a unique hardware and software design • New kind of security model for integrity, confidentiality and trust negotiation in an interconnected world

4. NGSCB Security Goals • Protect data and processing against software attack • Provide a strong way to authenticate machines and software. • Provide “compartmentalization” of secure applications • Small, dynamically materialized security perimeters with unspoofable TCBs • Provide safe haven in “network rich” environment

5. Key NGSCB Components    

6. Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS) Agent Agent Agent User Trusted User Engine (TUE) User Apps. TSP TSP TSP NCA Runtime Library Nexus Kernel NAL SSC Hardware Secure Input Secure Video CPU Chipset NGSCB Quadrants Main OS USB NexusMgr.sys Driver HAL

7. Attestation extends TCB • Another program can rely on this key without a central authority • Don’t try this at home, safe protocol is more complicated • May be replaced by Zero Knowledge Protocol • Program generates public/private key pair • Platform signs statement “The following public key is in an isolated program with hash H under Nexus N.”

8. Attestation Caveat • Attestation is NOT a judgment of code quality or fitness • Code could still be malicious • Code could still have bugs affecting security • Attestation leaves judgment up to challenger • Done with high confidence

9. What Runs On The LHS • Windows as you know it today • Applications and Drivers still run • Viruses too • Any software with minor exceptions • The new hardware (HW) memory controller won’t allow certain “bad” behaviors, e.g., code which • Puts the CPU into real mode

10. What the RHS Needs From The LHS • Memory Management changes to allow nexus to participate in memory pressure and paging decisions • Window Manager coordination • IPC, scheduling, communication • NGSCB management software and services

11. Secure Real Time Messaging • Secure Mail • Secure Distributed Processing • Employee use of Enterprise Programs • Employee use of Enterprise Data • Doctors access hospital records • Guard machines from untrusted network • Guard network from untrusted machines • Guard programs from untrusted services • Secure machine monitor • Lock-down and monitor machine policy • Sandbox execution Business Scenarios Secure Communication Secure Remote Access Secure Network Access Secure Machine Policy

12. Protect data on user machine • Protect spoofed machines and users • Provide Secure Audit • Protect personal data at Amazon • Secure RMS from software attack • Protect Corporate Partner Information • Books, movies, audio, software • Flexible use models: Differential pricing • Content not “orphaned” by new devices • Auctions • Negotiations • On-line Games Business Scenarios Confidentiality Enforcement “Small” Rights Management “Big” Rights Management Secure Collaboration

13. NGSCB: Threat Models • Our Threat Model • No Software-Only Attacks Against RHS • No Break-Once/Break-Everywhere (BOBE) attacks • No Software-Only Attacks means… • No attacks based on micro-code, macro-code, adapter card scripts, etc. • Any attacks launched from the Web or e-mail are “software only” • Protection only applies to the release of secrets

14. HW Keys: Whose are they? • Answer: The Hardware • Used only under explicit user policy. • NGSCB uses two hardware keys directly: • One key is used by Sealed Storage • Generated when user “takes ownership” • Only available to TPM • Randomizing • One key is an RSA key used for Attestation • Only signs statements like “Nexus with hash x asked me to sign the following statement: y.” • Privacy safeguards built into hardware • Opt-in • Disclosure of (public) signing key components is restricted • Use of keys in sole control of machine owner

15. Other Keys: Whose are they? • Answer: Entities authorized by users to access key services • User’s personal Keys • Service provider’s Keys • Shared Keys • Microsoft neither owns nor has access to any HW keys. • Key ownership is circumscribed and may not even be known to entity relying on it.

16. Machine owner is in complete control • Hardware cannot be used without explicit user permission • No nexus can run without explicit user permission • No NCA can run without explicit user permission • No NCA can use key services without user permission

17. Policies • Everything that runs today will run on NGSCB systems • The platform will run any nexus • The user will be in charge of what nexuses he chooses to run • The MS nexus will run any application • The user will be in charge of the applications that he chooses to run • The MS nexus will interoperate with any network service provider • The MS nexus source code will be made available for review

18. Misconceptions: NGCSB • NGSCB will censor or disable content without user permission • No policy (except user policy) in NGSCB • NGSCB will lock out vendors • No permission (signatures) required to use NGSCB • NGSCB is “super” virus spreader • NGSCB applications do no run at elevated privilege • NGSCB NCA is not debuggable • Yes it is. • This will hurt smart card vendors • No, it increases portable smart card value

19. Misconceptions: TCPA/TCG • It’s the Fritz chip • Nope. It’s an anti-Fritz chip. • TCPA/TCG refuses to run unlicensed software • Nope. Statement publicly denied by MS, HP and IBM. • Control will be exercised centrally • No central authorities required • Need for central authorities diminished • TC will remove effective control of PC from its owner • Strengthens owner control

20. User Apps. NGSCB Quadrants Standard-Mode (“std-mode” / LHS) Nexus-Mode (RHS) Agent Agent Agent User Trusted User Engine (TUE) TSP TSP TSP NCA Runtime Library Nexus Main OS Kernel USB NexusMgr.sys Driver NAL HAL SSC Hardware Secure Input Secure Video CPU Chipset

21. “Booting” The Nexus • Nexus is like an OS kernel, so it must boot sometime • Can boot long after main OS • Can shut down long before main OS (and restart later)

22. Boot a Nexus

23. Nexus: Basic Environment • Section 1 of Intro to Operating Systems Textbook • Process and Thread Loader/Manager • Memory Manager • I/O Manager • Security Reference Monitor • Interrupt handing/Hardware abstraction • But no Section 2 • No File System • No Networking • No Kernel Mode/Privileged Device Drivers • No Direct X • No Scheduling • No… • Kernel mode has no pluggables • All of the kernel loaded at boot and in the PCR

24. Nexus: Basic Environment • Virtualization of hardware fundamentals for Agents • Sealed storage, attestation, etc. • Minimal Services • Trusted UI Engine • XML Based Graphical Services for UI • Input Routing/Focus Management • Minimum Fonts (inc. Multiple Languages…) • Windows Manager • IPC • TSPs (Trusted Service Provider) • Run in User Mode RHS • Provide Services • Are “Drivers” for Trusted Input/Video

25. Close-Up Of Nexus

26. Code Identity • Nexus • Cryptographic Hash • Agents • Manifest (or rather hash of manifest) • Debugging Policy • Public Key • Corresponding Private key authorized to name cryptographic hashes of binaries that identify “this program” • Metadata

27. Debugging The Nexus • The retail nexus cannot be debugged • The debug nexus can be debugged • Since these two nexuses are different in at least one bit, their attestations are different as well

28. User Mode Debugging • No agents are debuggable without a change to their code identity • Attestation reflects this change • Debugging the LHS Shadow Process means debugging the Agent • We’ve redirected the functions to Get and Set Thread Context and Read and Write Process Memory • We’ve redirected RHS debug events to the LHS process • Thread control “just works” • Well behaved debuggers that work with LHS processes will also with agents

29. NGSCB: Seal • Here’s a good mental model • Seal(secret) → cryptoblob(secret) • Crytoblob(secret) may be stored anywhere • The call is really • Seal(secret, DigestOfTargetEnvironment) → cryptoblob(secret) • Unseal(cryptoblob(somesecret)) → somesecret • Unseal is really • Unseal(cryptoblob(somesecret), DigestOfTargetEnvironment) → somesecret

30. Secret Migration • Caller gets to specify certain properties • What agents may unseal the secret • What hardware may unseal the secret • What nexus may unseal the secret • What users may unseal the secret • Agents shouldn’t seal against the SSC • They should seal against the nexus • which seals against the SSC • Backup, restore, migration are all possible using intermediate keys and certificates

31. WIIFM: Credential Based Security • Single simple, flexible, scalable, distributed, credential based security model • Programs, users, machines, channels as principals • Fine-grained, persistent, declarative claim/assertion/authorization language • General authentication and authorization primitives • Manageable and Flexible • Non brittle • Administrable • Projects Security Perimeter outside Enterprise • Framework for policy enforcement • Desktop Lockdown • Policy assurance (Virus policy, IDS, …) • Supports migration of existing Windows security services