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
Security

Resilient to attack Protects confidentiality, integrity, availability, and data

Privacy

Individuals control personal data Products and Online Services adhere to fair information principles

Reliability

Dependable 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 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

Product Goal

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)
Agent

Nexus-Mode (RHS)
Agent Agent

User
User Apps.

Trusted User Engine (TUE) TSP TSP TSP

NCA Runtime Library

Main OS

Kernel
USB Driver NexusMgr.sys

Nexus

NAL

HAL

Hardware

Secure Input

Secure Video

SSC

CPU

Chipset

Four NGSCB Features Groups

1
The first three are needed to protect against malicious code Attestation breaks new ground in distributed computing
The identity of hardware, nexus, and applications can be proven

4
3

Addressing Customer Needs With NGSCB

Remote access

Granularity of access at machine, nexus, and application level Application to application connection rather than VPN connection IT can specify that only a known configuration of nexus and application can execute or access corporate resources Reinforce rights management by rooting key pair in hardware Encryption of data based on secrets that never leave hardware Agents identity is rooted in secrets on the hardware Applications run in isolated process space and are impermeable to software attack End users can collaborate and communicate securely End users can establish content authenticity by digital signature

Patch management

Preventing illegal access of information

Agents development

Collaboration enablement

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)
Agent

Nexus-Mode (RHS)
Agent Trusted User Engine (TUE) TSP TSP TSP NCA Runtime Library Agent

User
User Apps.

Main OS

Kernel
USB

Nexus

Driver

NexusMgr.sys 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 Changes to CPU, chipset Nexus arbitrates page tables

Enforced by hardware and software

Four Key Features

(2) Secure Path To and From User
Standard-Mode (LHS) Nexus-Mode (RHS)

User

Secure Video Filter Driver

Shadow Service

Admin Service

Nexus Mgr IPC Nexus Dispatch Services

Nexus Manager Core

Kernel Secure Input Filter Driver

Object Security Shared Resource Manager Manager

HW Allocator (memory wholesaler)

Nexus Loader

Nexus Manager Abstraction Layer (NMAL)

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 channel between graphics adaptor and nexus Changes to graphics adaptor Changes to video driver

Secure output

Four Key Features

(3) Sealed Storage
Standard-Mode (LHS) Nexus-Mode (RHS)

Agent

Agent

Agent

Trusted User Engine (TUE) TSP

User

TSP

TSP

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

User

TSP

TSP

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 Video

Secure 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 Chat and instant messaging E-Mail Rights management Digital signature

Secure collaboration

Secure Remote Access

Examples

To a client/server app, using a custom NCA client To your enterprise desktop, using a secure remote desktop client 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

How it works

Application-to-application encrypted session More secure than a VPN because the protection extends into the application layer itself

Application Private Network

Application (Client NCA) Presentation Session Transport Network Datalink Physical Application (Server) Presentation Session Transport Network Datalink 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

Mic ros oft Word Fi l e Ed i t Vi e w In se rt He l p Si g te xt th a l y... Th i s i sn Di g i ta t l sh o u l d b e ve ri fi e d a s co rre ct a n d th e n si g n e d .

Wh e n th e u se r w a n ts to sig n , th e te xt is re n d e re d b y th e a p p lica tio n in to a sta n d a rd XML -b a se d fo rma t a n d p a sse d to th e d ig ita l sig n a tu re agent

Se c ure Digita l Signa ture Th i s i s te xt th a t sh o u l d b e ve ri fi e d a s co rre ct a n d th e n si g n e d .

NOTE: for explanatory purposes only; this is not actual UI

Si g n a tu re : USPS Si g n a tu re

Si g n Ca n ce l

Wh e n th e u se r clicks sig n , th e XML d a ta is sig n e d a n d th e sig n e d d a ta is re tu rn e d to th e a p p lica tio n

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)
Agent

Nexus-Mode (RHS)
Agent Trusted User Engine (TUE) TSP TSP TSP Agent

User
User Apps.

NCA Runtime Library

Main OS

Kernel
USB Driver NexusMgr.sys

Nexus

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 dont 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 dont scale with the CPU

Adding main memory wont 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 Very obscure exceptions Profound change in what can be believed, and hence, trusted

Run all the old code

Qualitatively different

What Does NGSCB Do?

Enhances Security

Vault to store important material

Both locally and remotely attestable Control given to software, by users

Realistic control over which code can touch which data

Enhances Robustness

Better user control of what can run in NGSCB; what it can do Users can know which code is doing what with private information Users can delegate privacy decisions in a usable way

Enhances Privacy

How Does NGSCB Work

New kind of process, called a Nexus Computing Agent, or NCA, or Agent

Very much like a traditional process, but runs 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 From other agents From the Left Hand Side (LHS) Not even debuggers or device drivers can alter the agent at runtime

The agent is isolated

The agent has someplace to keep a secret On clients, agents will have a secure path to the user

NGSCB: Context
Standard-Mode (LHS) User Mode
User Programs

What exists in todays systems

DLL

DLL

Kernel Mode
Main OS

Drivers

HAL

Main OS is rich, compatible with vast array of stuff, supports vast array of hardware it is large User can install drivers which get privileged access to memory remote parties can never be sure the program has not been negatively impacted by the driver

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

User
NxSvc.exe User Apps.

Agent

Agent

Agent

Main OS

Kernel
Driver HAL NexusMgr.sys

Nexus NAL

Hardware

Secure Input

Secure Video

SSC

CPU

Chipset

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

User
NxSvc.exe User Apps.

Agent

Agent

Agent

Main OS

Kernel
Driver HAL NexusMgr.sys

Nexus NAL

Hardware

Secure Input

Secure Video

SSC

CPU

Chipset

NGSCB: Strong Process Isolation

Machine is locked into flat paged mode Address-Translation-Control prohibits stdmode 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 Secret not revealed Secret not a privacy hazard

This secret never leaves the SSC

NGSCB: Attestation Example

Digest1 is for the SSC

Establishes confidence in validity of NGSCB hardware Establishes confidence in validity of nexus Has meaning only if Digest1 is valid

Digest2 is for the nexus

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

Heres a good mental model

Seal(secret) cryptoblob(secret)

Crytoblob(secret) may be stored anywhere

Seal(secret, DigestOfEnvironment, DigestOfCallingAgent, MigrationControls) cryptoblob(secret)

The call is really

Unseal(cryptoblob(somesecret)) somesecret BUT Unseal is really

Unseal(cryptoblob(somesecret), DigestOfEnvironment, DigestOfCallingAgent) somesecret | nothing If the Digest of the environment or the calling agent does not match with those that did the seal, Unseal returns ** NOTHING **

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
They should seal against the nexus

Agents shouldnt seal against the SSC

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
USB Host Controller

E
E = Encrypted

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

User

Kernel

Hazard

E
E = Encrypted

USB Host Controller

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

User

Kernel

Hazard
USB Host Controller

E
E = Encrypted

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

User

Kernel

Hazard
USB Host Controller

E
E = Encrypted

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

User

Kernel

Hazard
USB Host Controller

E
Decrypted Text

E = Encrypted

Mobile PC Secure Input

Standard-Mode (std-mode/LHS) Nexus-Mode (RHS)

User
Chipset South Bridge (LPC bus Controller) Key Board Controller (KBC)

E
Hazard
E = Encrypted

Kernel

Secure Input

Encryption for Human Interface Device (HID) will be done on the outboard side of a USB host
1. 2.

3.
4.

Built into USB root hub Built into any USB hub Inside the device of interest 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 wont require it

Secure Video
Standard-Mode (std-mode/LHS) Nexus-Mode (RHS)

User
Graphics Adaptor (nexus-mode) Graphics Adaptor (std-mode) USB Host Controller

Kernel

Hazard

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 Adaptor (nexus-mode) Graphics Adaptor (std-mode) USB Host Controller

Hazard

Kernel

Crypto Path T-Vid

Standard-Mode (std-mode/LHS) Nexus-Mode (RHS)
Trusted Video Abstractor

User
Graphics Adaptor (nexus-mode) Graphics Adaptor (std-mode) USB Host Controller

Kernel

Hazard

E = Encrypted

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 CPU Chipset SSC Secure Input Secure 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 delays in market support

We are working closely with core-logic vendors to minimize risk

For RHS input and output its important to get things right

This means that there will be a small number of practical *INTERFACES* 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 normal ways

Nexus Fundamentals

Device Drivers

NGSCB doesnt 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 doesnt 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 wont 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 nexus to participate in memory pressure and paging decisions User mode debugger additions to allow debugging 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
NGSCB Calls Memory Manager Sync Objects
Porch Nx* Functions Syscall Dispatcher (Nexus Callable Interfaces)

Thread Manager

Process Loader

Native SRM

IO Manager

Process Manager

Runtime Library

Traps
ATC Module

Nexus Core Handle Mgr Crypto SSC Abstractor

Kernel debug Int Handler

Nexus Abstraction Layer (NAL)

I Think, Therefore I Am
Descartes Problem

Challenge for attestation must always come from outside the machine

Local (the user with a superkey) Remote (some server)

No nexus can directly determine if it is running in the secured environment No Agent can directly determine if it is running in the secured environment Must use Remote Attestation or Sealed Storage to cache credentials or secrets to prove the 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 wont 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 wont 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 The Microsoft nexus will run any agent

Proposed software (nexus) policies

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 Ive 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

Microsofts 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)
Agent

Nexus-Mode (RHS)
Agent Agent

User
User Apps.

Trusted User Engine (TUE) TSP TSP TSP

NCA Runtime Library

Main OS

Kernel
USB Driver NexusMgr.sys

Nexus

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 Video Filter Driver

Shadow Service

Admin Service

Nexus Mgr IPC Nexus Dispatch Services

Nexus Manager Core

Kernel Secure Input Filter Driver

Object Security Shared Resource Manager Manager

HW Allocator (memory wholesaler)

Nexus Loader

Nexus Manager Abstraction Layer (NMAL)

Hardware

Secure Input Secure video

Booting The Nexus

NexusMgr is a kernel mode LHS component

Read and map the nexus code Allocate some pages from the main OS Pass that list of pages to the nexus via some platform-specific code/hardware Digest the nexus (with hardware help)

Now the nexus starts, initializes Address Translation Control (ATC), and returns control to the LHS

Address Translation
Normal Page

Virtual addresses

Address Translation

Normal Page

Protected Page

Address Translation Control

This is curtained memory (or strong process isolation) Cant 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 Theres untrusted code in kernel mode Page map changes (process swap) Edits to mapping structures Turning off paging

NGSCB hardware calls nexus before

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 kernel via NexusMgr (seize) Nexus MM asks ATC if new pages are safe to use - any left side mappings? Nexus can give surplus pages back to kernel 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 Sowhat if an interrupt for the NIC, SCSI card, 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 Combined with ATC, this means PCI config space is protected Things like the DMA exclusion list are in chipset registers, so we must protect them

I/O ports

The NAL helps decide what to protect