Next-Generation Secure Computing Base

The Next-Generation Secure Computing Base (codenamed Palladium) is a software architecture originally slated to be included in the Microsoft Windows "Longhorn" operating system. Development of the architecture began in 1997.

The NGSCB was the result of years of research within Microsoft to create a secure computing solution that equaled the security of more closed systems while preserving the openness and flexibility of the Windows platform. The NGSCB relied on new software components and specially designed hardware to create a new execution environment where more sensitive operations could be performed securely. Microsoft's primary stated objective with the NGSCB was to "protect software from software."

History

The idea of creating an architecture where software components can be loaded in a known and protected state predates the development of NGSCB. A number of attempts were made in the 1960s and 1970s to produce secure computing systems, with variations of the idea emerging in more recent decades.

In 1999, the Trusted Computing Platform Alliance, a consortium of various technology companies, was formed in an effort to promote trust in the PC platform. The TCPA would release several detailed specifications for a trusted computing platform with focus on features such as code validation and encryption based on integrity measurements, hardware based key storage, and attestation to remote entities. These features required a new hardware component designed by the TCPA called the Trusted Platform Module (referred to as a Security Support Component, Secure Cryptographic Processor, or Security Support Processor in earlier Microsoft documentation). While most of these features would later serve as the foundation for Microsoft's NGSCB architecture, they were different in terms of implementation. The TCPA was superseded by the Trusted Computing Group in 2003.

Development

Development of the NGSCB began in 1997 after Microsoft developer Peter Biddle conceived of new ways to protect content on personal computers.

Microsoft later filed a number of patents related to elements of the NGSCB design. Patents for a digital rights management operating system, loading and identifying a digital rights management operating system, key-based secure storage, and certificate based access control were filed on January 8, 1999. A method to authenticate an operating system based on its central processing unit was filed on March 10, 1999. Patents related to the secure execution of code and protection of code in memory were filed on April 6, 1999.

During its Windows Hardware Engineering Conference of 2000, Microsoft showed a presentation titled Privacy, Security, and Content in Windows Platforms which focused on the protection of end user privacy and intellectual property. The presentation mentioned turning Windows into a "platform of trust" designed to protect the privacy of individual users. Microsoft made a similar presentation during WinHEC 2001.

The NGSCB was publicly unveiled under the name "Palladium" on 24 June 2002 in an article by Steven Levy of Newsweek that focused on its origin, design and features. Levy stated that the technology would allow users to identify and authenticate themselves, encrypt data to protect it from unauthorized access, and allow users to enforce policies related to the use of their information. As examples of policies that could be enforced, Levy stated that users could send e-mail messages accessible only by the intended recipient, or create Microsoft Word documents that could only be read a week after they were created. To provide this functionality, the technology would require specially designed hardware components, including updated processors, chipsets, peripherals, and a Trusted Platform Module. In August 2002, Microsoft posted a recruitment advertisement seeking a group program manager to provide vision and industry leadership in the development of several Microsoft technologies, including its NGSCB architecture.

In 2003, Microsoft publicly demonstrated the NGSCB for the first time at its Windows Hardware Engineering Conference and released a developer preview of the technology later that year during its Professional Developers Conference.

Diagram of NGSCB architecture revision shown during WinHEC 2004.

During WinHEC 2004, Microsoft announced that it would revise the technology in response to feedback from customers and independent software vendors who stated that they did not want to rewrite their existing programs in order to benefit from its functionality. After the announcement, some reports stated that Microsoft would cease development of the technology. Microsoft denied the claims and reaffirmed its commitment to delivering the technology. Later that year, Microsoft's Steve Heil stated that the company would make additional changes to the technology based on feedback from the industry.

In 2005, Microsoft's lack of continual updates on its progress with the technology had led some in the industry to speculate that it had been cancelled. At the annual Microsoft Management Summit event, then Microsoft CEO Steve Ballmer said that the company was building on the foundation it had started with the NGSCB to create a new set of hypervisor technologies for its Windows operating system. During WinHEC 2005, Microsoft announced that it had scaled back its plans for the technology in order to ship the post-reset Windows "Longhorn" operating system within a reasonable timeframe. Instead of providing an isolated software environment, the NGSCB would offer full operating system volume encryption with a feature known as Secure Startup (which would later be renamed as Bitlocker Drive Encryption). Microsoft stated that it planned to deliver other aspects of its NGSCB architecture at a later date.

In July 2008, Peter Biddle stated that negative perception was the main contributing factor responsible for the cancellation of the architecture.

Name

In Greek and Roman mythology, the term "palladium" refers to an object that the safety of a city or nation was believed to be dependent upon.

On 24 January 2003, Microsoft announced that "Palladium" had been renamed as the "Next-Generation Secure Computing Base." According to NGSCB product manager Mario Juarez, the new name was chosen not only to reflect Microsoft's commitment to the technology in the upcoming decade, but also to avoid any legal conflict with an unnamed company that had already acquired the rights to the Palladium name. Juarez acknowledged that the previous name had been a source of criticism, but denied that the decision was made by Microsoft in an attempt to deflect criticism.

Architecture

NGSCB essentially would have divided the computing environment into two separate and distinct operating modes. Thus, NGSCB would have been composed of two parts: the traditional "left-hand side" (LHS) and the “right-hand side” (RHS) security system. The LHS and RHS would have been a logical, but physically enforced, division or partitioning of the computer.

The LHS would have been composed of traditional applications such as Microsoft Office, along with a conventional operating system, such as Windows. Drivers, viruses, and any software with minor exceptions would also have run on the LHS. However, the new hardware memory controller would not have allowed certain "bad" behaviors. Examples would have been code which copied all of memory from one location to the next, or which put the CPU into real mode. Another term for the LHS is standard mode.

Meanwhile, the RHS would have worked in conjunction with the LHS system and the central processing unit (CPU). With NGSCB, applications would have run in a protected memory space that is highly resistant to software tampering and interference. The RHS or nexus mode would have been composed of a “nexus” and trusted agents, called Nexus Computing Agents. The RHS would also comprise a security support component that would have used a public key infrastructure key pair along with encryption functions to provide a secure state. Other terms for the RHS are the nexus mode or the isolated execution space, in which the nexus and NCAs would have executed.

Typically, there would have been one chipset in the computer that both the LHS and RHS would have used.

The RHS was required not to rely on LHS for security. If adversarial LHS code were present, NGSCB must not leak secrets. However, the RHS was required to rely on the LHS for stability and services. NGSCB would not have run in the absence of LHS cooperation. NGSCB needed the following from the LHS:

* Basic OS services - scheduler

• 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

— Brandon Baker, A Technical Introduction to NGSCB,

NGSCB would not have changed the device driver model, resorting to secure reuse of LHS driver stacks whenever possible (i.e., RHS encrypted channel through LHS unprotected account). NGSCB would have needed very minimal access to real hardware. Every line of privileged code was considered a potential security risk. Therefore, there would have been no third-party code nor kernel-mode plug-ins.

• 

  Diagram of the NGSCB software architecture as presented during WinHEC 2003.

• 

  "FIG. 2 is a block diagram of an existing NGSCB system having both trusted and untrusted environments" (Source: US7530103B2 patent) Note how the RHS and LHS correspond to the WinHEC 2003 diagram.

Nexus

Diagram of the Nexus design.

The nexus, previously referred to as the "Nub" or "Trusted Operating Root" would have been the new kernel introduced by the NGSCB. The nexus would have been responsible for the secure interaction between the specialized hardware components, and would also have been responsible for the isolation and management of Nexus Computing Agents.

The nexus was described either as like a kernel, a “high assurance” operating system, as an operating system component, or as a secure system component. As a basic OS, the nexus would have been composed of (and not of) the following features:

* Section 1 of Intro to Operating Systems Textbook

• • Process and Thread Loader/Manager
  • Memory Manager
  • I/O Manager
  • Security Reference Monitor
  • Interrupt handling/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 hashed in the TPM

— Brandon Baker, A Technical Introduction to NGSCB,

The nexus could boot any time, could shut down when not needed, and could restart later. It would have started in a controlled initial state. Nexus startup would have been atomic and protected in a controlled initial state.

The nexus would have hosted, protected, and controlled NCAs.

In a patent granted in favor of Microsoft, the nexus was described as:

A nexus is a “high assurance” operating system that provides a certain level of assurance as to its behavior and can comprise all the kernel mode code on the RHS. For example, a nexus might be employed to work with secret information (e.g., cryptographic keys, etc.) that should not be divulged, by providing a curtained memory that is guaranteed not to leak information to the world outside of the nexus, and by permitting only certain certified applications to execute under the nexus and to access the curtained memory. The nexus 251 should not interact with the main operating system 201 in any way that would allow events happening at the main operating system 201 to compromise the behavior of the nexus 251. The nexus 251 may permit all applications to run or a machine owner may configure a machine policy in which the nexus 251 permits only certain agents to run. In other words, the nexus 251 will run any agent that the machine owner tells it to run. The machine owner may also tell the nexus what not to run.

The nexus 251 isolates trusted agents 255, 260, manages communications to and from trusted agents 255, 260, and cryptographically seals stored data (e.g., stored in a hard disk drive). More particularly, the nexus 251 executes in kernel mode in trusted space and provides basic services to trusted agents 255, 260, such as the establishment of the process mechanisms for communicating with trusted agents and other applications, and special trust services such as attestation of a hardware/software platform or execution environment and the sealing and unsealing of secrets. Attestation is the ability of a piece of code to digitally sign or otherwise attest to a piece of data and further assure the recipient that the data was constructed by an unforgeable, cryptographically identified software stack.

— Bryan Mark Willman, Paul England, Kenneth D. Ray, Keith Kaplan, Varugis Kurien, Michael David Marr, Projection of trustworthiness from a trusted environment to an untrusted environment,

NGSCB would have allowed a PC to run one nexus at a time. The hardware would have loaded any nexus, but only one at a time.

Each nexus would have gotten the same services. The hardware would have kept nexus secrets separate. Nothing about this architecture would have prevented any nexus from running.

NGSCB would have enforced policy but would not have had set the policy. The owner could control which nexuses are allowed to run.

On the software side, Microsoft would have built a nexus designed to complement Windows, and expected other developers and vendors to build nexuses of their own. The Microsoft nexus would run any agent. The platform owner could set policy that limits this. The owner could pick some other delegated evaluator if they choose.

Nexus Computing Agents

Nexus Computing Agents (NCAs), or trusted agents would have been application processes strictly managed by the nexus. They would have consisted of user-mode code executing within the isolated execution space (nexus mode). An NCA could have been be an application in and of itself, or an NCA could have been part of an application that would have also run in the standard Windows environment. In other, words, an NCA or trusted agent could have been a program, a part of a program, or a service that runs in user mode in trusted space. Each NCA would have had access only to the memory allocated to it by the nexus. This memory would not have been shared with other processes on the system, unless explicitly allowed by the NCA.

An NCA trusted agent would call the nexus for security-related services and critical general services, such as memory management. Each NCA would have had access only to the memory allocated to it by the nexus. This memory would not have been shared with other processes on the system, unless explicitly allowed by the NCA. A NCA or trusted agent would have been able to store secrets using sealed storage and to authenticate itself using the attestation services of the nexus. Each trusted agent or entity would have controlled its own domain of trust, and they need not have relied on each other.

Nexus Computing Agents were divided into three categories: "Application," "Component," and "Trusted Service Provider."

Features

Developers could have used four main capabilities to protect data against software attacks on NGSCB systems: strong process isolation, sealed storage, secure paths to and from the user, also called secure input and output, and attestation. All NGSCB-enabled application capabilities would have been built off of these four key features or pillars. The first three would have been needed to protect against malicious code.

Strong process isolation

Strong process isolation would have been a mechanism for protecting data in memory. It would have been created and maintained by the nexus and enforced by NGSCB hardware and software. Hardware would have notified the nexus of certain operations, and the nexus would have arbitrated page tables, control registers, and others.

Agents and the nexus would have run in curtained memory, inaccessible to other agents, to the standard Windows kernel, nor to hardware DMA. It would have provided an execution and memory space, a trusted space by carving out a secure area (the RHS). This space would have been protected from external access and software-based attacks (even those launched from the kernel). Operations that run on the RHS would have been protected and isolated from the LHS, which would have made them significantly more secure from attack. In other words, strong process isolation would have prevented rogue applications from changing NGSCB data or code while it was running.

Sealed storage

Sealed storage would have been a mechanism for protecting data in storage. It would have allowed the user to encrypt information with a key rooted in the hardware, so that it could only be accessed by a trustworthy application, the designated trusted entity that stored it, or by authenticated entites. The trustworthy application could have included just the application that created the information in the first place, or any application that was trusted by the application that owned the data. Therefore, sealed storage would have allowed a program to store secrets that could not be retrieved by nontrusted programs, such as a virus or Trojan horse, and sealed storage would have prevented rogue applications from getting at your encrypted data. Sealed storage would also have verified the integrity of data when unsealing it.

Each nexus would have generated a random keyset on first load. The TPM chip on the motherboard would have protected the nexus keyset. Agents would have used nexus facilities to seal (encrypt and sign) private data. The nexus would have protected the key from any other agent/application, and the hardware would have prevented any other nexus from gaining access to the key.

Secure paths to and from the user

Secure paths to and from the user would have been mechanisms for protecting data moving from input devices to the NCAs, and from NCAs to the monitor screen. Protected input devices were the keyboard and mouse. Secure input meant USB for desktops, integrated input for laptops. Data entered by the user and presented to the user could not be read by software such as spyware or “Trojan horses.” Malicious software could not mimic or intercept input, or intercept, obscure or alter output. Secure path would have enabled one to be sure that they are dealing with the real user, not an application spoofing the user.

With NGSCB, keystrokes would have been encrypted before they could be read by software and decrypted once they reach the RHS. This meant that malicious software could not be used to record, steal or modify keystrokes.

Secure output would have been similar. A secure channel would have existed between the nexus and the graphics adapter. The information that would have appeared onscreen could be presented to the user so that no one else could intercept it and read it. Taken together, these things would have allowed a user to know with a high degree of confidence that the software in his computer is doing what it was supposed to do.

Attestation

Attestation would have been a mechanism for authenticating a given software and hardware configuration, either locally or remotely. Attestation would have let other computers know that a computer was really the computer it claimed to be, and was running the software it claimed to be running. It would have based on secrets rooted in hardware combined with cryptographic representations (hash vectors) of the nexus and/or software running on the machine. Attestation would have been a core feature for enabling many of the privacy benefits in NGSCB. Because NGSCB software and hardware would have been cryptographically verifiable to the user and to other computers, programs, and services, the system could verify that other computers and processes were trustworthy before engaging them or sharing information. Thus, attestation would allowed the user to reveal selected characteristics of the operating environment to external requestors. Attestation involved secure authentication of subjects (e.g., software, machines, services) through code ID. This would have been separate from user authentication.

When requested by an agent, the nexus could have prepared a chain that authenticates: the agent by digest, signed by the nexus; the nexus by digest, signed by the TPM; and the TPM by public key, signed by the OEM or the IT department. The machine owner would have set policies to control which forms of attestation each agent or group of agents could use. A secure communications agent would have provided higher-level services to agent developers. It would have opened a secure channel to a service using a secure session key, and responded to an attestation challenge from the service based on user policy.

Neither nexus nor agent could directly determine if it is running in the secured environment. They would have been required to use Remote Attestation or Sealed Storage to cache credentials or secrets to prove the system is sound.

Hardware

Encrypted memory was once considered for the NGSCB, but the idea was later discarded as the only threat conceived of that would warrant its inclusion was the circumvention of digital rights management technology.

Trusted Platform Module

The Trusted Platform Module is the hardware component that securely stores the cryptographic keys for the Nexus and Nexus Computing Agents, which makes the sealed storage and attestation features of the Nexus possible.

The Trusted Platform Module includes an asymmetric 2048-bit RSA key pair, referred to as the Endorsement Key (EK), which is unique to each particular module and is generated as part of its manufacturing process. The public key is accessible to applications or services that have established a trusted relationship with the owner, and is also used to provide the owner with Attestation Identity Keys (AIKs).

According to Microsoft, version 1.2 of the Trusted Platform Module is the first version compatible with its NGSCB architecture. Previous versions do not include the required functionality.

In builds of Windows "Longhorn"

A successful attempt to configure the Next-Generation Secure Computing Base in Windows "Longhorn" build 4053.

In released pre-reset builds of Windows "Longhorn", NGSCB components reside in %SYSTEMDRIVE%\WINDOWS\NGSCB. The last build of Windows "Longhorn" known to include the NGSCB directory and subfolders is build 4066.

Legacy

The development of the Next-Generation Secure Computing Base ultimately led to the creation of Microsoft's Bitlocker drive encryption feature, which was one of the first mainstream device encryption features to support version 1.2 of the Trusted Platform Module, and the first device encryption feature to be integrated with the Windows operating system. Certain design elements of the NGSCB would become part of Microsoft's virtualization technologies. Windows 8, released in 2012, includes a feature called Measured Boot which allows a trusted server to verify the integrity of the Windows startup process. Although it is not directly related to the NGSCB architecture, it serves a purpose comparable to the architecture's attestation feature in that they are both designed to validate a platform's configuration.

In addition, features based on those originally intended for the NGSCB would later become available in competing operating systems. In 2012, Giesecke & Devrient produced a parallel execution environment called MobiCore for the Android operating system designed to host secure user applications and protect confidential data. In 2013, Apple released a new feature for its iOS operating system called Secure Enclave to protect a user's biometric information.

External links

Microsoft

• Microsoft Next-Generation Secure Computing Base Home Page, from the Wayback Machine
  • Earlier capture from June 2003, with WinHEC 2003 links
  • Microsoft Next-Generation Secure Computing Base Documentation, with links to resources from the Microsoft site on NGSCB

BetaArchive

• Builds of "Longhorn" with NGSCB?
• Longhorn 4033 Privacy Preferences
• Windows "Longhorn" features present in Windows Vista, includes some NGSCB features
• "Longhorn" NGSCB patents expired