Next-Generation Secure Computing Base: Development Considerations for Nexus Computing Agents

  • Article

 

By Ellen Cram
Microsoft Corporation

October 2003

Applies to:

   The 2003 Microsoft Professional Developers Conference (PDC) release of the Next-Generation Secure Computing Base (NGSCB) technologies
   Microsoft® Windows®

Summary: Provides guidelines for software developers who understand the broad architectural principles of the Next-Generation Secure Computing Base (NGSCB) for Microsoft Windows family of operating systems and who want to learn more about writing Nexus computing agents (NCAs). (12 printed pages)

Contents

Introduction
NCAs and the Nexus: How NCAs Function on the NGSCB
Benefits
Scenarios: Developing Custom Internet-enabled Business Solutions
Planning an NCA
Conclusion
For More Information

Introduction

The Next-Generation Secure Computing Base (NGSCB) is an innovative platform that provides a more secure and trustworthy computing environment to Microsoft Windows users. The NGSCB offers a powerful and flexible solution to users whose work requires greater data security, personal privacy, or system integrity. Working on NGSCB-capable computers users can perform routine tasks in Standard mode using their existing applications, services, and devices. For their high-security tasks, those same users can run trusted, authenticated Nexus computing agents (NCAs) that execute in a separate and protected operating environment called Nexus mode.

Nexus mode provides a higher level of protection against malicious programs designed to damage users' computers or to access their personal information. Developers can build trusted NCAs that run exclusively in Nexus mode, or they can modify existing applications and services that run in Standard mode to launch and communicate with NCAs running in Nexus mode. NCAs can secure data and processes at a much higher level of certainty than applications in Standard mode.

The following are examples of applications that could use Nexus mode to better protect their data and processes:

  • Any application that must store and protect important or sensitive data written to disk such as financial or medical records.
  • Any application that must protect data in memory such as instant messaging.
  • Any application that must protect user input such as passwords or logon secrets.
  • Any application that must verify the legitimacy of other applications or other entities that it relies on. For example, an application on a remote server that must verify the legitimacy of a client application before it proceeds with an important transaction or an exchange of private data.

To help you better understand the basic guidelines for writing applications and services for the NGSCB, this white paper includes the following sections:

  • NCAs and the Nexus: How NCAs Function on the NGSCB. Describes how NCAs interact with the Nexus.
  • Benefits. Discusses the benefits of writing an NCA.
  • Scenarios: Developing Custom Internet-enabled Business Solutions. Describes common scenarios using NCAs.
  • Planning an NCA. Steps through the basic planning decisions you must make as you develop an NCA.
  • For More Information. Provides a list of resources for obtaining additional information about the NGSCB.

NCAs and the Nexus: How NCAs Function on the NGSCB

The NGSCB divides the computing environment into two separate and distinct operating modes: Standard mode, where the Windows kernel and existing applications execute, and Nexus mode, where the Nexus security kernel and NCAs execute. While standard Windows continues to function in Standard mode, the Nexus hosts and controls NCAs, and it protects them from any harmful programs that may be running in Standard mode.

The Nexus executes in kernel mode within a secure memory space. It uses standard virtual memory protections to isolate itself from NCAs and to isolate NCAs from one another. In addition, the Nexus establishes privileged access to certain I/O devices (including the mouse, keyboard, and monitor). That privileged access creates a secure path between the user and the Nexus, and provides trusted input and output to and from each NCA.

To minimize its size, the Nexus is designed to implement only those services required by developers to write NCAs and that are critical to its integrity—for example, access control and memory isolation. Beyond those components, the Nexus and its NCAs rely on the main operating system for standard services such as scheduling (the Nexus cryptographically protects data before exposing it to the main operating system).

From the point of view of an NCA, the Nexus provides a set of APIs and services, including sealed storage and attestation functions. In addition, the Nexus performs the following on behalf of NCAs:

  • Services requests from NCAs and manages all essential NGSCB services, including memory management, exclusive access to device memory (including secure input and output), and access to any services outside of the NGSCB environment.
  • Starts NCAs on behalf of other applications, and then runs each NCA in its own isolated and protected process space, called protected memory.
  • Facilitates communications between NCAs.
  • Facilitates communications between an NCA running in Nexus mode and an application running in Standard mode.
  • Provides cryptographic services to NCAs, including key storage, encryption and decryption of data that is entered, stored, communicated, or displayed.
  • Identifies and authenticates NCAs.
  • Controls access to trusted applications and resources.

Benefits

There are four main benefits to developing an NCA: secure input and output, protected memory, attestation, and sealed storage.

Secure Input and Output

Secure input and output in the NGSCB refers to a secure path that runs from the keyboard and mouse to NCAs and then from those NCAs to trusted windows under their control. To create those secure and trusted communication paths, the NGSCB uses secure input and output devices. Currently, those devices include upgraded keyboards and universal serial bus (USB) devices. As other input and output devices such as smart cards, biometrics, and video cards are made trustworthy, the NGSCB will provide interfaces for them as well.

Secure input and output devices ensure that user data comes from and goes to authorized locations without being intercepted. When used with the NGSCB, they help to protect against programs that record keystrokes or enable a remote user or program to act as a legitimate local user.

In addition, NGSCB technology includes a Trusted User Interface Engine (TUE) that offers high-level services to NCAs that must display and manage a user interface. The NCA specifies the UI using an XML-based format, and then manipulates that UI by using the functions provided by the TUE or by using custom event handlers that the NCA registers with the TUE.

Agents running in Nexus mode get trusted input and output as a benefit of running in Nexus mode. Nothing is required of you as the developer to ensure that the input and output to your NCA is secure.

Protected Memory

Protected memory addresses the problems that result when code that is external to the executing program can access, snoop, modify memory, or affect the program in an unintended or malicious way.

Protected memory in the NGSCB refers to a secure, isolated area of memory the Nexus creates for each NCA within the memory space the Nexus controls. Each NCA runs in a restricted and protected address space, a completely separate process that other programs cannot access.

Note   Although NCAs cannot share memory, they can communicate with other agents or applications through an interprocess communication (IPC) layer.

The Nexus provides NCAs with strong process isolation by setting aside a specific portion of the available RAM on the computer and blocking any program that is running in the user space memory from accessing that address space. Process isolation helps to ensure that NCAs are not modified or observed by any other program. Even the Standard mode kernel cannot access an NCA running in protected memory.

An NCA is also protected from direct memory access (DMA) devices reading or writing to its memory. The NGSCB uses a special structure to specify, page-by-page, the areas of memory the Nexus has curtained off as secure and are thus inaccessible to DMA transfers. As a consequence, information from the computer's hard disk must be read into the operating system or user space memory first and then, if necessary, an NCA moves it into protected memory.

Agents running in Nexus mode run in protected memory. Nothing is required of you as the developer to ensure that your NCA is running in its own protected memory space.

Attestation

Attestation addresses the problem of how to ensure the identity and authentication of computers and the programs that run on them. To ensure the legitimacy of an identity or authentication, a trusted entity "attests to" that legitimacy using methods at your discretion.

For the 2003 Microsoft Professional Developer Conference (PDC) release, attestation in the NGSCB refers to a process in which one entity digitally signs and attests to a piece of data, authenticating the entity requesting the attestation and validating the integrity of its data. Attestation provides a stronger security foundation for tasks that could potentially pose security risks. Using attestation, NCAs can create, verify, and maintain a security perimeter that does not require trusted administrators or authorities.

In a typical scenario, a server might attest to a client as follows:

  1. The client creates a message (part of which is the digest, computed by the Nexus, of the currently running NCA), computes a digest on that message, and signs that digest. It then sends those objects (the original message, a digest of that message, a signed digest of that message, and a public key certificate) to the server.
  2. The server compares the two digests of the agent it has available—one that the Nexus computed when it started the client, and the other a known and trusted digest computed when the client was first introduced to the system. If the two digests match, the server continues. Otherwise, attestation fails.
  3. Assuming that step 2 succeeds, the server computes a digest on the message it receives from the client and compares that digest to the digest on the message that the client computed and sent. If the two match, the server continues. Otherwise, attestation fails.
  4. Assuming that step 3 succeeds, the server attempts to verify the client's signature. If the server can verify the signature, the attestation succeeds. Otherwise the attestation fails.

It is important to understand that the NGSCB does not dictate how a given enterprise implements the server-side attestation. Each enterprise is free to determine the required level of security, whether or not to build a database of trusted digests, and so on.

To take advantage of attestation, use the Attestation API.

Sealed Storage

Sealed storage addresses the problem that results when a program encrypts and stores data on a computer, and then stores the encrypting keys unsecured on the same computer.

For the 2003 Microsoft Professional Developer Conference (PDC) release, sealed storage in the NGSCB refers to a mechanism that uses encryption to help ensure the privacy of data an NCA stores on external devices. It does so by binding a unique secret or key to a specific NCA, encrypting that secret to disk, and then requiring that only that NCA access the data.

In a typical scenario, NCAs that store data might do the following:

  1. Encrypt the data using AES encryption and save that encrypted information to disk.
  2. Call SealNx and pass to it the secret used to encrypt the data along with a digest of your NCA. SealNx seals the secret to the digest, outputs an encrypted blob, and stores it to disk. To decrypt the data it originally encrypted, your NCA must first access the sealed secret.
  3. To access the sealed secret, your NCA calls UnSealNx and passes to it a pointer to the sealed blob, along with a copy of its digest. If UnSealNx can verify that your NCA's digest matches the digest in the sealed blob, it unseals the key. Otherwise, the call to UnSealNx fails.
  4. Assuming UnSealNx unseals the key, your NCA can then use the key to decrypt the data it originally encrypted.

To take advantage of Sealed Storage, use the Sealed Storage API.

Scenarios: Developing Custom Internet-enabled Business Solutions

Suppose you worked for an enterprise that asks you to create an NCA for its customers and employees. The NCA must ensure secure remote access and protect sensitive transactions over the Internet.

As a developer in the enterprise, you could build a stand-alone NCA or a component NCA to satisfy those requirements.

Stand-alone NCAs

A stand-alone NCA contains all of the desired functionality and runs entirely in Nexus mode. It does not rely on other components running in Standard mode to complete its operations.

For example, if you worked for a financial service company that provides NGSCB-capable computers to its high-end customers, you might design an NCA to run entirely in Nexus mode and use a secure network protocol that would enable users to communicate with a server application on the company's servers. The NCA could use attestation to prove its identity to the server application before any sensitive transactions were processed. The attestation would prevent malicious users from intercepting or tampering with customer data and activities, and it would protect the server from transactions initiated by malicious programs and unauthorized users.

Similarly, if you worked for a medical enterprise that asked you to create a way to maintain the privacy of online medical records, you might design an NCA that doctors could use remotely to access those records over the Internet from NGSCB-capable computers. The doctors could log in with a secure client application that uses a secure network protocol to interact with the hospital server and enable the doctors to view and edit their patient data without compromising that data.

Component NCAs

A component NCA contains only the secure components of the desired functionality, and works in tandem with an application running in Standard mode. A component NCA is typically designed to appear as a component object model (COM) or managed object to a standard application. The two communicate using transports over an IPC layer.

For example, if you worked for an enterprise that asked you to develop an intranet page to display and manipulate information about employees, you might create a standard application that all employees could use to view public information about other employees. Then you could create an NCA that a restricted group of administrators could launch from the intranet page in order to display more sensitive information such as salary, promotion, and so on. Your standard application would provide most of the functionality. Your NCA could request attestation from the server to ensure that malicious users were not attempting to access or modify privileged information, to provide encryption and decryption services of sensitive data, and to seal the keys so that even if an intruder gained access to the encrypted data, the intruder could not view the data without the keys.

Planning an NCA

Before you write an NCA, consider the questions discussed in this section. For convenience, this paper uses the term application to discuss a program running in Standard mode and the term NCA to discuss a program running in Nexus mode.

What are you trying to protect?

Consider building an NCA or incorporating an NCA component into an existing application if one or more of the following is true:

  • You must protect data that is written to disk. (Your NCA can encrypt the data, and then seal the encrypting keys on the same disk or on a different external storage device to protect the keys from any other application or agent.)
  • You must protect a given sequence or set of manipulations your data undergoes, prevent users' actions from being recorded, or prevent intruders from using a debugger to watch what the user is doing with the NCA. (Because each NCA executes in protected memory, no other program can view or access any action your NCA takes on your data.)
  • You must prevent users' actions from being spoofed on an application server. (You can require attestation between the NCA and the server.)
  • You must protect data that users input. (Nexus mode automatically protects user input to the NCAs running under its auspices.)
  • You must protect data that you output. (You can use the TUE to display and manage output in trusted windows.)
  • Other entities on a remote server must verify that your program is legitimate. For example, another application might need to verify your application's legitimacy before starting important transactions or sending private data. (You can require attestation between the NCA and the remote server.)

What threats are you protecting against?

While the NGSCB excels at protecting data and processes in Nexus mode, it does not address vulnerabilities in Standard mode or the physical security of your computer, and it cannot mitigate those risks for you. Before you write your program, construct a list of the potential security vulnerabilities you foresee and how you intend to solve them. Consider building an NCA or incorporating an NCA component into your program if the NGSCB is appropriate to those threats.

If the threat or vulnerability you see would be mitigated by one of the following, then an NCA is an appropriate solution. Otherwise, it may not be.

  • Trusted input and output.
  • Strong process isolation.
  • Sealing keys or secrets to hardware.
  • Ensuring the integrity of a piece data or the legitimacy of an identity.

What type of NCA do you need?

The type of NCA you need depends on the task you have at hand. There are three types of NCAs: stand-alone, component, and Trusted Service Provider.

  • Stand-alone NCAs run entirely in Nexus mode and do not rely on other components running in Standard mode to complete their operations.
  • Component NCAs contain only the secure components of a desired set of functionality, and they work in tandem with an application running in Standard mode. A component NCA is typically designed to appear as a COM or managed object to a standard application. The two communicate using transports over an IPC layer.
  • Trusted Service Provider NCAs run entirely in Nexus mode and provide services to other NCAs. For example, the TUE is such an NCA.

Relative to Standard mode, Nexus mode is a very restricted development environment. For that reason, most developers will partition their programs so that agents in Nexus mode manage critical trusted information, and applications in Standard mode manage traditional functionality.

A useful analogy is to think of Standard mode as the living space in your house and Nexus mode as a fireproof safe in your house. While having a fireproof safe is a very good idea if you have important documents to protect, you would not want to build your living room inside that safe.

In the same way, you would typically take advantage of the rich functionality in Standard mode to develop most of your features, and then create an NCA to safeguard only the most sensitive information or critical tasks such as encryption, signature generation/verification, data integrity, trusted input/output, and so on.

For example, you would:

  • Write most of a text editor in Standard mode, and then write a small NCA to sign user documents that were generated in that editor. (See the TxtViewer and Secure Notepad samples that ship with the Microsoft Windows Code-Named "Longhorn" SDK.)
  • Write the majority of a database application in Standard mode, and then write a small NCA to modify a restricted group of privileged records.
  • Write a secure instant messenger client and server almost entirely in Nexus mode. (See the Secure Chat sample that shipped with the "Longhorn" SDK.)

A good rule of thumb is: If you can leave functionality in Standard mode without compromising information, you should leave it there. Following that guideline will help you to more easily partition your applications between standard and Nexus modes. You may even be able to implement secure enhancements to an existing application by writing some transport code in that application, and then writing a simple agent that runs in Nexus mode and performs the desired enhancements on behalf of the application.

Beyond that general rule, consider the following implicit advantages and restrictions that flow logically from the NGSCB security benefits:

Protected memory considerations

When your NCA runs in Nexus mode, it runs in its own isolated process space. While this has several powerful advantages that were discussed earlier, it also creates some side effects that may not be immediately obvious:

  • There is no shared memory in Nexus mode. To share information, you must use transports over the IPC layer, and data that you send over transports cannot include pointers to protected memory addresses.
  • You cannot read and write to another process's memory in Nexus mode.
  • You cannot create a thread in another process running in Nexus mode.
  • To debug an NCA, you must use the latest version of the "Longhorn" PDC Preview Debugging Tools for Windows, which you can download from the Microsoft Debugging Tools Web site.

Note   You cannot currently use Microsoft Visual Studio® to debug an NCA.

Communication considerations

When your NCA must communicate with another NCA running in Nexus mode or with an application running in Standard mode, it uses transports over the IPC layer. NCAs communicate with other agents by using Nexus transports. Applications in Standard mode use Standard Transports to communicate with NCAs. Alternatively, those standard applications can use the Transport Manager, which accepts managed code and outputs managed IPC wrappers.

As you design your NCAs, keep the following transport considerations in mind:

  • While your NCA can communicate with other agents and applications over the IPC pipe, you must flatten the data you pass through that pipe. For example, you cannot pass pointers to protected memory addresses.
  • While the IPC pipe can accommodate large amounts of data, the data may not flow as quickly as you would like. You may want to design your NCAs to pass the least amount of data through that pipe as you can.
  • Because the scheduler must coordinate between Standard mode and Nexus mode, if you have a lot of data to transport over the IPC layer, it is better to send the data in large chunks than in several small messages, each of which must be scheduled separately.
  • If you must share secure information, it should not cross the boundary between Nexus mode and Standard mode without protection. For example, if you write an NCA that processes a password and then hands the password to an application running in Standard mode, you must protect that password before passing it to Standard mode.

User Interface considerations

If your NCA requires a user interface, you must provide an XML file that describes the desired UI using the Trusted Service Provider Interface Definition Language (TSPIDL). After you have provided that document, the Trusted UI Engine (TUE) renders and manages your UI and alerts your NCA when events occur on active UI elements. Your NCA can set properties on the elements in and modify the structure of the XML document. In addition, an NCA can map distinct event IDs to one or more event handlers in such a way that when the TUE detects the event ID, the TUE dispatcher calls the event handler mapped to that ID.

The code snippet below is a simple UI example that is a variation on the classic Hello World theme. It uses a window that has the text "Hello World!" along the top and an Add button below it. When you click the Add button, an OK button replaces it. An event handler for the OK button is installed as well. With the event handler in place, clicking the OK button closes the window.

CONST WCHAR *gHelloWorld = 
L"<DockPanel>"
L"  <FlowPanel Margin=\"5\" Dock=\"Top\">Hello World!</FlowPanel>"
L"  <FlowPanel Dock=\"Top\" ID=\"ButtonPanel\">"
L"    <Button ID=\"Add\" Margin=\"3\">Add</Button>"
L"  </FlowPanel>"
L"</DockPanel>";

CONST WCHAR *gOKButton = L"<Button ID=\"OK\" Margin=\"3\">OK</Button>";
static STATUS

/* Routine Description: This causes the UI to close by signaling the 
   "done" parameter passed in through the "Data" parameter.*/

lOKButton (    IN NX_UI_HANDLE Dlg, IN NX_UI_HANDLE Dispatch,  
   IN CONST WCHAR *ID, IN VOID *Data )
{
  PBOOL done = (PBOOL)Data;
  *done = TRUE;
  return STATUS_SUCCESS;
}

static STATUS

lAddButton ( IN NX_UI_HANDLE Dlg, IN NX_UI_HANDLE Dispatch, IN CONST WCHAR *ID, IN VOID *Data )

/* Routine Description:   This replaces the contents of the element ButtonPanel 
   with the XML fragment    gOKButton. Visually, the OK button replaces the 
      Add button. The routine then installs an event handler for the OK button. */
{
  STATUS status;
  
  status = NxRendSetXMLContent( Dlg, L"ButtonPanel", gOKButton);

  if (SUCCESS( status )) {

    status = NxRendRegisterEvent( Dispatch, L"OK", lOKButton );

    if (SUCCESS( status )) {

      status = NxRendDraw( Dlg, TRUE );
    }
  }
  return status;
}

Conclusion

This paper covered how NCAs interact with the Nexus, the benefits of developing NCAs and common scenarios that illustrate those benefits, key decisions you must make before writing an NCA, and development considerations you should take into account before writing an NCA.

For More Information

To learn more about the NGSCB and NGSCB NCAs, see the following:

  • For more information about the underlying concepts and architecture of the NGSCB, see the Next-Generation Secure Computing Base Web page.
  • For more information about setting up your build environment and developing, building, and debugging an NCA, see the Programming Guide in the Next-Generation Secure Computing Base node in the "Longhorn" SDK documentation.
  • For more information about the NGSCB APIs, see the NGSCB Unmanaged Reference and the NGSCB Managed Reference in the Next-Generation Secure Computing Base node of the "Longhorn" SDK documentation.
  • For more information about the samples that ship with the NGSCB, see the Programming Guide in the Next-Generation Secure Computing Base node in the "Longhorn" SDK documentation.

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2003 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.