Transcript MSR Summer Institute

Next Generation Secure
Computing Base
John Manferdelli
[email protected]
Security Business Unit
Microsoft Corporation
The Problem
Remote
Edge
IPsec
Network level
Encryption
Core
data, IP, apps, “secrets”
“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
SSL
ACL
VA tools
Reporting
tools
Monitoring
tools
Air gap network
VPN
Config and
patch mgt
Encryption
HSM
Network
IDS
Content
screening
Network
Firewall,
segmentationCorp network Proxy server
2-factor authentication, one time
password, digital signature
Antivirus software
Personal firewall
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
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
Key NGSCB Components




NGSCB Quadrants
Standard-Mode (“std-mode”/LHS)
Nexus-Mode (RHS)
Agent
User
Agent
Agent
Trusted User
Engine (TUE)
User Apps.
TSP
TSP
TSP
NCA Runtime Library
Main OS
Nexus
Kernel
USB
NexusMgr.sys
Driver
NAL
HAL
Hardware
Secure Input
Secure Video
SSC
CPU
Chipset
Attestation extends TCB


Program generates public/private key
pair
Platform signs statement “The
following public key is in an isolated
program with hash H under Nexus N.”



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
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
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
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
Business Scenarios

Secure
Communication
Secure Remote
Access
Secure Network
Access
Secure Machine
Policy











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
Confidentiality
Enforcement



“Small” Rights
Management

“Big” Rights
Management

Secure
Collaboration







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
NGSCB: Threat Models

Our Threat Model



No Software-Only Attacks means…



No Software-Only Attacks Against RHS
No Break-Once/Break-Everywhere (BOBE) attacks
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
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




One key is an RSA key used for Attestation


Generated when user “takes ownership”
Only available to TPM
Randomizing
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
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.
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
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
Misconceptions: NGCSB

NGSCB will censor or disable content without
user permission


NGSCB will lock out vendors


NGSCB applications do no run at elevated privilege
NGSCB NCA is not debuggable


No permission (signatures) required to use NGSCB
NGSCB is “super” virus spreader


No policy (except user policy) in NGSCB
Yes it is.
This will hurt smart card vendors

No, it increases portable smart card value
Misconceptions: TCPA/TCG

It’s the Fritz chip
 Nope.

TCPA/TCG refuses to run unlicensed software


Nope. Statement publicly denied by MS, HP and
IBM.
Control will be exercised centrally



It’s an anti-Fritz chip.
No central authorities required
Need for central authorities diminished
TC will remove effective control of PC from its
owner

Strengthens owner control
NGSCB Quadrants
Standard-Mode (“std-mode” / LHS)
Nexus-Mode (RHS)
Agent
User
Agent
Agent
Trusted User
Engine (TUE)
User Apps.
TSP
TSP
TSP
NCA Runtime Library
Main OS
Nexus
Kernel
USB
NexusMgr.sys
Driver
NAL
HAL
Hardware
Secure Input
Secure Video
SSC
CPU
Chipset
“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)
Boot a Nexus
Nexus: Basic Environment

Section 1 of Intro to Operating Systems Textbook






But no Section 2







Process and Thread Loader/Manager
Memory Manager
I/O Manager
Security Reference Monitor
Interrupt handing/Hardware abstraction
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
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
Close-Up Of Nexus
Nexus.exe
Nx* Functions
NGSCB
Calls
Syscall Dispatcher
(Nexus Callable Interfaces)
ATC
Module
Handle
Mgr
Nexus Abstraction Layer (NAL)
Runtime
Library
Nexus Core
Native SRM
IO Manager
Thread Manager
Process
Manager
Traps
Process Loader
Memory
Manager
Sync
Objects
Porch
Kernel
debug
Crypto
SSC
Abstractor
Int
Handler
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
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
User Mode Debugging

No agents are debuggable without a change to their
code identity


Debugging the LHS Shadow Process means
debugging the Agent




Attestation reflects this change
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
NGSCB: Seal

Here’s a good mental model

Seal(secret) → cryptoblob(secret)


The call is really



Crytoblob(secret) may be stored anywhere
Seal(secret, DigestOfTargetEnvironment) →
cryptoblob(secret)
Unseal(cryptoblob(somesecret)) →
somesecret
Unseal is really

Unseal(cryptoblob(somesecret),
DigestOfTargetEnvironment) → somesecret
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
WIIFM: Credential Based
Security

Single simple, flexible, scalable, distributed, credential based
security model




Manageable and Flexible




Non brittle
Administrable
Projects Security Perimeter outside Enterprise
Framework for policy enforcement



Programs, users, machines, channels as principals
Fine-grained, persistent, declarative claim/assertion/authorization
language
General authentication and authorization primitives
Desktop Lockdown
Policy assurance (Virus policy, IDS, …)
Supports migration of existing Windows security services