Next Generation

Secure Computing
Base

黃志源
@SiS
Contents
 Next Generation Secure Computing
Base Overview
 Hardware Fundamentals For NGSCB
Part 1: Core Hardware
 Hardware Fundamentals For NGSCB
Part 2: Peripheral Hardware
 Nexus Fundamentals
Next Generation Secure
Computing Base Overview
Trustworthy Computing
 Resilient to attack
Security  Protects confidentiality, integrity,
availability, and data

Individuals control personal data

Privacy
Products and Online Services adhere to fair
information principles
Dependable
Reliability Available when needed
Performs at expected levels
Help customers find appropriate solutions
Business Integrity Address issues with products and services
Open interaction with customers
NGSCB Vision And Goals
 Vision
 NGSCB advances the PC ecosystem to meet
customers’ requirements for security, privacy,
and data protection
 Product Goal
 NGSCB will broaden the utility of the PC by
delivering security on par with closed
architecture systems while maintaining the
flexibility of the Windows platform
 Business Goal
 NGSCB will help to revitalize the PC ecosystem
by enabling a new generation of hardware and
software products
Customer Security Issues
 Vulnerability introduced by enabling
remote access
 Illegal access and usage of sensitive
information
 Difficulty in knowing who a company is
doing business with
 Difficulty in doing patch management
 Others
 Collaborating in a secure environment
 Protecting secrets, e.g., key pairs, certificates
 Virus and malicious code attacks
Why NGSCB?
 Vulnerabilities today
 Attacks on Core assets
 Attacks on Networks
 Attacks via Remote users/machines
 NGSCB can address software attacks
on applications, secrets
 Damage from attacks can be
compartmentalized and limited
How It Works: The PC
How It Works: Before NGSCB
How It Works: Before NGSCB
How it Works: Before NGSCB
How It Works: With NGSCB

NGSCB
How It Works: With NGSCB
How It Works: With NGSCB

NGSCB
 NGSCB Quadrants
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

Agent Agent Agent

User
Trusted User
Engine (TUE)
User Apps.
TSP TSP TSP

NCA Runtime Library

Main OS
Kernel Nexus

USB NexusMgr.sys
Driver NAL

HAL

Hardware Secure Input Secure Video SSC CPU Chipset

Four NGSCB Features Groups
The first three are
1 needed to protect
against malicious
code
Attestation breaks
new ground in
4 2 distributed
computing
The identity
of hardware,
nexus, and
3 applications can
be proven
Addressing Customer Needs
With NGSCB
 Remote access
 Granularity of access at machine, nexus, and application level
 Application to application connection rather than VPN connection
 Patch management
 IT can specify that only a known configuration of nexus and application can
execute or access corporate resources
 Preventing illegal access of information
 Reinforce rights management by rooting key pair in hardware
 Encryption of data based on secrets that never leave hardware
 Agents development
 Agents identity is rooted in secrets on the hardware
 Applications run in isolated process space and are impermeable to
software attack
 Collaboration enablement
 End users can collaborate and communicate securely
 End users can establish content authenticity by digital signature
Four NGSCB Features Groups
What Does This All Mean?
 All NGSCB capabilities build off of four key features
 Strong process isolation
 Root key for persistent secret protection
 Secure path to and from the user
 Attestation (hardware (HW)/software (SW) authentication)
 The first three are needed to protect against malicious
code
 Attestation breaks new ground in
distributed computing
 “Things” (software, machines, services) can be
securely identified
NGSCB Quadrants

Standard-Mode (LHS) Nexus-Mode (RHS)

Agent Agent Agent

User Trusted User

Engine (TUE)
User Apps.
TSP TSP TSP

NCA Runtime Library

Main OS
Kernel Nexus

USB NexusMgr.sys
Driver
NAL

HAL

Hardware Secure Input Secure Video SSC CPU Chipset

 Four Key Features
(1) Process Isolation
Standard-Mode (LHS) Nexus-Mode (RHS)

Agent Agent Agent

User

Trusted User
Engine (TUE)

TSP TSP TSP

NCA Runtime Library

Kernel

Hardware
Strong Process
Isolation
 Nexus Computing Agents, or NCAs,
run in curtained memory
 Not accessible by the standard
Windows kernel
 Not accessible by hardware DMA
 Not accessible by other NCAs
 Enforced by hardware and software
 Changes to CPU, chipset
 Nexus arbitrates page tables
 Four Key Features
(2) Secure Path To and From User
Standard-Mode (LHS) Nexus-Mode (RHS)

User

Secure
Shadow Admin Nexus Mgr
Video Service Service IPC
Filter Driver

Nexus
Nexus Manager Core Dispatch
Secure Services
Kernel Input
Filter Driver HW Allocator
Object Security Shared Resource
(memory
Manager Manager
wholesaler)

Nexus Manager Abstraction Layer (NMAL) Nexus Loader

Hardware Secure Input Secure video

Secure Path To User
 Secure input
 Encrypted session between USB device
and nexus
 Changes to standard USB driver stack
 Required for keyboard and mouse
 Alternate solution being developed for
non-USB (laptops)
 Secure output
 Secure channel between graphics adaptor
and nexus
 Changes to graphics adaptor
 Changes to video driver
 Four Key Features
(3) Sealed Storage
Standard-Mode (LHS) Nexus-Mode (RHS)

Agent Agent Agent

Trusted User
Engine (TUE)

TSP TSP TSP

User
NCA Runtime Library

Kernel

Nexus

NAL

Hardware SSC
Hardware Protection
Of Secrets
 Security Support Component (SSC)
chip on motherboard
 SSC holds a secure keyset
 Each nexus generates a random keyset
on first load
 SSC provides hardware protection of the
nexus keyset
 NCAs use nexus facilities to generate
and protect keys
 Four Key Features
(4) Attestation
Standard-Mode (LHS) Nexus-Mode (RHS)

Agent Agent Agent

Trusted User
Engine (TUE)

TSP TSP TSP

User
NCA Runtime Library

Kernel

Nexus

NAL

Hardware SSC
Attestation
Software/Hardware Authentication

 When requested, the nexus can prepare a

chain that authenticates
 NCA by digest, signed by the nexus
 Nexus by digest, signed by the SSC
 SSC by public key, signed by OEM
 Other forms of attestation are possible that
provide less information
 Using trusted third party
 User sets policy to control which NCAs can
use which forms of attestation
 Hardware Summary
Standard-Mode (LHS) Nexus-Mode (RHS)

User

Kernel

Hardware
SSC

Secure Secure
Video Input CPU Chipset
Hardware Summary
 Modified components
 CPU
 Chipset
 Secure video
 Secure input (keyboard and mouse)
 Two versions: USB and laptop
 New components
 SSC
A Qualitative Step Forward
 NGSCB extends the Windows platform
 We provide the core, others will build the
solutions
 We really want to enable others to build new and
exciting applications
 NGSCB is appropriate anywhere you could
possibly imagine needing privacy, security or
data protection
 We will ship some solutions “in the box”
 Enough to provide immediate value
Scenario Categories
 Secure remote access
 Corporate remote access
 Secure client access to middle tier servers
 Secure collaboration
 Chat and instant messaging
 E-Mail
 Rights management
 Digital signature
Secure Remote Access
 Examples
 To a client/server app, using a custom NCA client
 To your enterprise desktop, using a secure remote
desktop client
 How it works
 Uses attestation for end-to-end authentication
 Uses strong process isolation and secure path to the
user to be safe against attacks on the remote client
 Uses an application private network (APN) for
secure communications
 Application-to-application encrypted session
 More secure than a VPN because the protection extends
into the application layer itself
Application Private Network
Application Application
(Client NCA) (Server)
Presentation Presentation
Session Session
Transport Transport
Network Network
Datalink Datalink
Physical Physical

Standard IP: vulnerable at every layer

VPN: network layer and below are protected,
including data on the wire – but all software on
the client has access to the server connection
NGSCB APN: extends protection to all
layers, so that only the client and server
applications can use the connection
Secure Collaboration
 Examples
 Secure e-mail
 Secure text document creation and sharing
 Secure instant messaging
 Secure digital signature – “what you see is what you sign”
 How it works
 Uses rights management based on hardware protection of
secrets to protect and control access to data
 Uses strong process isolation and secure path to the user to
be safe against spoofing and snooping attacks
 Uses an APN for end-to-end messaging security
 Secure Digital Signature
Microsoft Word
File Edit View Insert Help When the user wants to sign, the
ThisSign Digitally...
is text that should be verified as correct and then signed.
text is rendered by the application
into a standard XML-based format
and passed to the digital signature
agent

Secure Digital Signature

This is text that should be verified as correct and then signed.

NOTE: for When the user

explanatory clicks “sign”, the
XML data is signed
purposes Signature: USPS Signature
Sign and the signed
only; this is Cancel data is returned to
the application
not actual UI
Hardware Fundamentals
For NGSCB
Part 1: Core Hardware
Agenda
 Threat Models
 What is NGSCB and Why?
 What does NGSCB do?
 NGSCB Features and Details
 Strong Process Isolation
 Attestation
 Sealed Storage
 Call to Action
Next Generation Secure
Computing Base (NGSCB)
Defined
 New security technology for the Microsoft
Windows platform
 Unique hardware and software architecture
 Protected computing environment inside the
Windows PC
 A “virtual vault” that will sit side by side with the
regular Windows environment
 New kinds of security and privacy
protections for computers
 NGSCB Quadrants
Standard-Mode (LHS) Nexus-Mode (RHS)

Agent Agent Agent

User
Trusted User
Engine (TUE)
User Apps.
TSP TSP TSP

NCA Runtime Library

Main OS
Kernel Nexus

USB NexusMgr.sys
Driver
NAL

HAL

Hardware Secure Input Secure Video SSC CPU Chipset

NGSCB: Threat Models
 Our Threat Model
 NO Software-Only Attacks Against Nexus-Space
Operations
 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
 Viruses could still delete encrypted files
NGSCB: Threat Models
 No BOBE attacks means
 Attacks don’t scale
 Each Security Support Component (SSC) has
unique keys
 Data MUST use unique or partially unique,
rather than global keys
 One person breaking one machine yields
the secrets sent to that machine only
 Does NOT allow that person to tell everybody
else in the world how to break content
 Does allow the release of content bound to
that machine
What And Why?
 Modifications to allow PCs to be used in
new ways
 Hardware changes
 Software changes
 Allows users to interact with entities either
inside or outside the machine:
 Show them what code is running
 Make believable promises about code
 Prove that those promises are durable
 Changes what can be believed about
computation
 Not what can be done with it
What And Why?
 This is the Next Big Thing
 Windowing in the ‘80s
 Networking in the ‘90s
 Security in the ‘00s
 Security and trust will advance the
PC ecosystem
 Customers are demanding higher security
and privacy
 From end-users to enterprises
 Governments are mandating as well
 Opens new markets that rely on trustworthiness
of information technology
What Does NGSCB Do?
 Creates a safe region called nexus-space
inside of a regular PC
 Think of an access-controlled, high-security vault
in an open market
 All the rest of the PC is still present
 Apply full power and speed of the PC to
security functions
 Co-processors don’t scale with the CPU
 Adding main memory won’t speed them up
 Majority of the hardware is unchanged
 E.g., PCI, Serial, Parallel, Memory
What Does NGSCB Do?
 NGSCB Code on NGSCB Hardware
 Designed to stop all software only threats
in nexus-space
 Run all the old code
 Very obscure exceptions
 Qualitatively different
 Profound change in what can be believed,
and hence, trusted
What Does NGSCB Do?
 Enhances Security
 “Vault” to store important material
 Both locally and remotely attestable
 Realistic control over which code can touch which data
 Control given to software, by users
 Enhances Robustness
 Better user control of what can run in NGSCB; what it can do
 Enhances Privacy
 Users can know which code is doing what with private
information
 Users can delegate privacy decisions in a usable way
How Does NGSCB Work
 New kind of process, called a Nexus C
omputing Agent, or NCA, or Agent
 Very much like a traditional process, but r
uns in a much more spartan environment
 The Key Assertions may be applied
to agents
Key Assertions
 The agent is what it is attested to be
 The agent is running in the attested environment and
THEREFORE
 The agent will be initiated correctly
 Agent behavior cannot be permuted by attacking initialization
 The agent is isolated
 From other agents
 From the Left Hand Side (LHS)
 Not even debuggers or device drivers can alter the agent
at runtime
 The agent has someplace to keep a secret
 On clients, agents will have a secure path to the user
NGSCB: Context

Standard-Mode (LHS)
What exists in today’s
User systems
Mode  Main OS is rich,
User Programs compatible with vast
array of stuff,
DLL DLL supports vast array of
hardware – it is large
 User can install
Main OS drivers which get
Kernel privileged access to
Mode
memory – remote
Drivers parties can never be
sure the program has
HAL
not been negatively
impacted by the driver
NGSCB Quadrants
Standard-Mode (LHS) Nexus-Mode (RHS)

User
Agent Agent Agent
NxSvc.exe
User Apps.

Main OS
Kernel
Nexus

NexusMgr.sys
Driver NAL

HAL

Hardware Secure Input Secure Video SSC CPU Chipset

NGSCB Quadrants
Standard-Mode (LHS) Nexus-Mode (RHS)

User
Agent Agent Agent
NxSvc.exe
User Apps.

Main OS
Kernel
Nexus

NexusMgr.sys
Driver NAL

HAL

Hardware Secure Input Secure Video SSC CPU Chipset

NGSCB:
Strong Process Isolation
 Machine is locked into flat paged mode
 Address-Translation-Control prohibits std-
mode code from mapping a nexus-mode page
 No CPU access to memory w/out mapping
 Requires CR3 loads trap to nexus
 Requires alteration of maps
 Requires PTE-writes to trap to the nexus or be
filtered by hardware
 Chipset/Memory controller maintains a per-page
list of pages to which DMA is prohibited, period
NGSCB: Attestation
 Attestation is a crypto-signed digest
of some code
 Proof that some bit vector is known
by this digest
 SSC and CPU compute digest of nexus
at nexus boot
 Nexus computes the digest of agents
 Digests are gathered together to make
attestation vector that is passed back
to a challenger
NGSCB: Attestation
 Root of attestation stack is the security
support component (SSC)
 Proof valid because the SSC provides a
proof of a secret that only the SSC knows
 This secret never leaves the SSC
 Secret not revealed
 Secret not a privacy hazard
NGSCB: Attestation
Example
 Digest1 is for the SSC
 Establishes confidence in validity of NGSCB
hardware
 Digest2 is for the nexus
 Establishes confidence in validity of nexus
 Has meaning only if Digest1 is valid
 Digest3 is for the agent
 Establishes confidence in validity of agent
 Has meaning only if Digest1 and Digest2 are valid
NGSCB: Attestation Caveat
 Attestation is NOT a judgment of code
quality or fitness
 Hardware will run any nexus, and attest to
the digest of any nexus
 Our nexus will run any agent (in
accordance with user policy) and attest to
the digest of that agent
 Attestation leaves judgment up to
challenger
 Done with excellent confidence
 Not up to hardware/nexus
NGSCB: Attestation →
Hardware
 Attestation is implemented at the root
by the SSC
 Must be tightly bound to the CPU and the
chipset for
 Booting of the nexus
 Attestation of the nexus
 Chain of attestation
NGSCB: Seal
 Here’s a good mental model
 Seal(secret) → cryptoblob(secret)
 Crytoblob(secret) may be stored anywhere
 The call is really
 Seal(secret, DigestOfEnvironment, DigestOfCallingAgent,
MigrationControls) → cryptoblob(secret)
 Unseal(cryptoblob(somesecret)) → somesecret
 BUT – Unseal is really
 Unseal(cryptoblob(somesecret), DigestOfEnvironment, Di
gestOfCallingAgent) → somesecret | nothing
 If the Digest of the environment or the calling agent does
not match with those that did the seal, Unseal returns ** N
OTHING **
NGSCB: Seal
 What it means…
 If we ignore migration and indirection…
 Seal/Unseal say that if agent A running on environment B
seals a secret, then,
 Only agent A running on environment B can unseal it
 This gives agent A a way to hide a key
 Seal is implemented by the nexus in cooperation
with the SSC
 Same hardware build rules as for attestation
 What's an "environment"
 Matching attestation vector for nexus-mode only
 Booting some other OS that can call the SSC does NOT reveal
the secrets
NGSCB: Seal
 Migration and indirection
 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
Hardware Fundamentals
For NGSCB
Part 2: Peripheral Hardware
GSCB: Desktop Secure Input
 Threat Model
 NO Software Only Attacks Against Secured
Keystrokes
 NO Break-Once/Break-Everywhere (BOBE) attacks
 Out of scope
 People swapping the keyboard hardware
 Patching into the keyboard cable
 Sticking some device between the keyboard and
the box
 All require a physical attack
 Cannot send a physical attack via e-mail
Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Kernel
Hazard

USB
Host
Controller
Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Kernel
Hazard
E
USB
E Host
Controller
E = Encrypted
Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Kernel
Hazard
E
USB
E Host
Controller
E = Encrypted
Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Kernel
Hazard
E
USB
Host E = Encrypted
Controller

E
Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Kernel
Hazard
E
USB
Host E = Encrypted
Controller

E
Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Kernel
Hazard
E
Decrypted
Text
USB
Host E = Encrypted
Controller

E
Mobile PC Secure Input
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User
E
Chipset
Kernel South Bridge
(LPC bus Hazard
Controller)

E
Key Board
Controller
(KBC)
E = Encrypted
Secure Input
 Encryption for Human Interface Device
(HID) will be done on the outboard side
of a USB host
1. Built into USB root hub
2. Built into any USB hub
3. Inside the device of interest
4. In-line device (dongle) between the
machine and the input device
 Best solution is #1
Secure Input Work In Progress
 For desktops
 Evaluating several different ways of establishing
shared secret
 Security versus OEM and IT deployment tradeoffs
 For laptops
 Evaluating different ways to partition Secure Input
Path firmware/microcode in Embedded Controller
 Legacy versus security certification issues
 Alternatives being evaluated
 More information in calls-to-action
Secure Video
 Threat Model for video
 NO Software-Only attacks against Secure Windows
and the information displayed in them
 NO Break-Once/Break-Everywhere (BOBE) attacks
 This is not the ONLY hazard relevant to all
stake holders
 It is what we can secure
 Security for external video interfaces is a matter
for hardware standards
 NGSCB could support link protections but won’t require it
Secure Video
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

User

Graphics Kernel
Adaptor
(nexus-mode)

Graphics
Adaptor Hazard
(std-mode)

USB
Host
Controller
Secure Video
 Secure Video assures
 Secure windows cannot be obscured
 Secure windows cannot be captured by
unauthorized software
 Secure windows cannot be altered by
unauthorized software
 Graphics adaptor may communicate
with display in various formats
 We are working on accessibility
Secure Video
 The Challenge
 How does the video data get from
nexus-mode to the graphics processor?
 Two general ways
 Closed path – video MUST be integrated device
 Depends on special hardware path from nexus to
video device
 Works when the video device is in close cooperation
with the memory controller
 Encrypted path – data is encrypted in
nexus-mode and decrypted by the
graphics adaptor
 Can reuse LHS driver stack
Closed Path T-Vid
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

Trusted
Video
Abstractor

User

Graphics Kernel
Adaptor Hazard
(nexus-mode)

Graphics
Adaptor
(std-mode)

USB
Host
Controller
Crypto Path T-Vid
Standard-Mode (“std-mode”/LHS) Nexus-Mode (RHS)

Trusted
Video
Abstractor

User
E
Graphics Kernel
Adaptor
(nexus-mode) E
Graphics
Hazard
Adaptor
(std-mode)

USB
Host E = Encrypted
Controller
NGSCB: Ecosystem
 Works today on x86 flat 32-bit
architectures from multiple sources
 Could work on any CPU with
 User/kernel modes
 Page granular virtual memory mapping
 With effort, could be adapted to other
CPU models
NGSCB: Ecosystem
 Building an NGSCB capable machine
requires:
NGSCB NGSCB Secure Secure
SSC
CPU Chipset Input Video

All working in conjunction

Include tamper resistant/detecting hardware to pursue specific
opportunities
NGSCB: Changing The Nexus
 The digest of the nexus is the basis for trust in
the system
 So a change to the nexus is non-trivial
 Hardware changes which require nexus changes will face delay
s in market support
 We are working closely with core-logic vendors to minimize risk
 For RHS input and output it’s important to get
things “right”
 This means that there will be a small number of practical *INTER
FACES* for trusted-input and trusted-output
 This is about INTERFACES, not gates, technologies, fabs, speeds, or
costs; INTERFACES
 Microsoft is working to define these INTERFACES with leading
providers of video and USB hardware
 LHS interfaces and software can change in the norma
l ways
Nexus Fundamentals
Device Drivers
 NGSCB doesn’t change the device
driver model
 NGSCB needs very minimal access to
real hardware
 Secure reuse of Left Hand Side (LHS) driver
stacks wherever possible
 Right Hand Side (RHS) encrypted channel through
LHS unprotected conduit
 Every line of privileged code is a potential
security risk
 No third-party code
 No kernel-mode plug-ins
Partitioned System
 RHS = Security
 In the presence of adversarial LHS code
the system must not leak secrets
→ The RHS must NOT rely on the LHS
for security
 LHS = Richness and Compatibility
 In the absence of LHS cooperation
NGSCB doesn’t run
→ The RHS MUST rely on the LHS for stability
and services
What Runs On The LHS
 Applications and Drivers still run
 Viruses too
 Windows as you know it today
 Any software with minor exceptions
 The new hardware (HW) memory
controller won’t allow certain “bad”
behaviors, e.g., code which
 Copies all of memory from one location to
the next
 Puts the CPU into real mode
What NGSCB Needs From
The LHS
 Device Driver work for Trusted Input / Video
 Memory Management additions to allow nexu
s to participate in memory pressure and pagi
ng decisions
 User mode debugger additions to allow debu
gging of agents (explained later)
 Window Manager coordination
 Nexus Manager Device driver (nexusmgr.sys)
 NGSCB management software and services
Close-Up Of The Lower RHS

Nexus.exe Nx* Functions

Syscall Dispatcher
NGSCB
Calls

(Nexus Callable Interfaces)

Thread Manager
Process Loader

Native SRM
IO Manager
Manager

Manager

Runtime
Memory

Process
Objects

Library
Sync

Porch
Traps

Nexus Core Kernel

debug
ATC Handle
Crypto
Module Mgr
Int
SSC Handler
Nexus Abstraction Layer (NAL)
Abstractor
I Think, Therefore I Am
Descartes Problem
 Challenge for attestation must always come f
rom outside the machine
 Local (the user with a superkey)
 Remote (some server)
 No nexus can directly determine if it is runnin
g in the secured environment
 No Agent can directly determine if it is runnin
g in the secured environment
 Must use Remote Attestation or Sealed Stora
ge to cache credentials or secrets to prove th
e system is sound
Nexus Derivative Works
 The user can run any nexus, or write his
own and run it, on the hardware
 That nexus can only report the attestation
provided by the Security Support
Component (SSC)
 The SSC won’t lie
 The nexus cannot pretend to be another nexus
 Other systems will need to decide if they
trust the new derived nexus
 Just need to prove to others your derivative
is legitimate
Agent Derivative Works
 The user can run any agent, or write his
own and run it, on the nexus
 That agent can report the attestation
provided by the nexus
 The nexus won’t lie
 The agent cannot pretend to be
another agent
 Other systems will need to decide if
they trust the new derived agent
 Just need to prove to others your
derivative is legitimate
Policy Controlled By The
Owner Of The Machine
 NGSCB enforces policy but does not set the policy
 The hardware will load any nexus
 But only one at a time
 Each nexus gets the same services
 The hardware keeps nexus secrets separate
 Nothing about this architecture prevents any nexus from
running; however, the owner can control which nexuses are
allowed to run
 Proposed software (nexus) policies
 The Microsoft nexus will run any agent
 The platform owner can set policy that limits this
 User gets to pick some other delegated evaluator
(e.g., my union) if they choose
Policy Notes
 Policy is a way for users and machine
owners to make general, abstract
statements, about what software runs
 “Run any agent I click”
 “Run only agents whose source I’ve read”
 “Run agents that a third party I trust, trusts”
 The point of policy is to enable the
users to control what runs on their
machines
Next Generation Secure
Computing Base Defined
 Microsoft’s Next-Generation Secure
Computing Base (NGSCB) is a new
security technology for the Microsoft
Windows platform
 Uses a unique hardware and
software design
 Gives people new kinds of security and
privacy protections in an
interconnected world
 NGSCB Quadrants
Standard-Mode (“std-mode” / LHS) Nexus-Mode (RHS)

Agent Agent Agent

User
Trusted User
Engine (TUE)
User Apps.
TSP TSP TSP

NCA Runtime Library

Main OS
Kernel Nexus

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)
 NGSCB Nexus Manager

Standard-Mode (LHS) Nexus-Mode (RHS)

User

Secure
Shadow Admin Nexus Mgr
Video Service Service IPC
Filter Driver

Nexus
Nexus Manager Core Dispatch
Secure Services
Kernel Input
Filter Driver HW Allocator
Object Security Shared Resource
(memory
Manager Manager
wholesaler)

Nexus Manager Abstraction Layer (NMAL) Nexus Loader

Hardware Secure Input Secure video

“Booting” The Nexus
 NexusMgr is a kernel mode LHS compo
nent
 Read and map the nexus code
 Allocate some pages from the main OS
 Pass that list of pages to the nexus via so
me platform-specific code/hardware
 Digest the nexus (with hardware help)
 Now the nexus starts, initializes Addre
ss Translation Control (ATC), and retur
ns control to the LHS
Address Translation

Normal Page

Virtual
Address Normal Page
addresses Translation

Protected Page
Address Translation Control
 This is curtained memory (or strong
process isolation)
 Can’t tamper with a page unless you have a
mapping to it
 On current PCs
 Any kernel mode code can modify Virtual Address (VA) →
Physical Address (PA) mapping structures
 There’s untrusted code in kernel mode
 NGSCB hardware calls nexus before
 Page map changes (process swap)
 Edits to mapping structures
 Turning off paging
Address Translation Control
 When the page map changes,
the nexus
 Walks the tree of pages it maps
 Makes sure no protected pages are
mapped
 No read/write mappings to the page map
 Now the map will remain safe, so
hardware and software can manage a list
of known safe page maps
Address Translation Control
 When a mapping structure changes,
the nexus
 Walks the tree of pages getting mapped
 Makes sure no protected pages are
getting mapped
 Ensures no read/write mappings to the
page map
 ATC will almost always allow the
mapping to change
 Legacy code will still work unless it
attempts to access nexus space pages
Address Translation Control
 ATC protects
 Agent and nexus data
 Agent and nexus code
 All page mapping structures (LHS/RHS)
 Also protected from DMA (thanks to
special hardware)
 Correct ATC implementation vital to
NGSCB security
Memory Management (MM)
 Simplicity, robustness preferred over
maximizing performance
 Allocate/free whole pages
 No shared memory between agents
 No paging-to-disk in this version
 If nexus were to page to disk, it would
encrypt and sign the pages, then ask the
main OS to flush them
Memory Management (MM)
 Nexus keeps some free pages that ATC
is protecting
 Nexus can request extra pages from ke
rnel via NexusMgr (seize)
 Nexus MM asks ATC if new pages are s
afe to use - “any left side mappings?”
 Nexus can give surplus pages back to k
ernel if the kernel needs them
Nexus Abstraction Layer (NAL)
 Multiple CPU vendors
 Different Security Support Components
(SSC)
 Much nexus code is architecture
independent
Interrupts
 Interrupts enabled on the RHS
 Most drivers are still on the LHS

So…what if an interrupt for the NIC, SCSI c

ard, etc. happens on the right?
 Nexus asks Porch to transition to
the LHS
 NexusMgr “replays” the interrupt
Nexus Also Protects
 Model specific registers (MSRs)
 Some MSRs are used to implement NGSCB,
but most will be accessible by left side code
 I/O ports
 Combined with ATC, this means PCI config
space is protected
 Things like the DMA exclusion list are in chi
pset registers, so we must protect them
 The NAL helps decide what to protect