Microsoft Next-Generation Secure Computing Base - Technical FAQ
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
July 2003
On This Page
Next-Generation Secure Computing Base General Information
Next-Generation Secure Computing Base and TCG
Next-Generation Secure Computing Base and Digital Rights Management (DRM)
Next-Generation Secure Computing Base and Shared Source Licensing
Next-Generation Secure Computing Base and Unlicensed Software
Next-Generation Secure Computing Base General Information
Q: What is the Next-Generation Secure Computing Base?
A: The Next-Generation Secure Computing Base (NGSCB) is new security technology for the Microsoft® Windows® platform. It will be included as part of an upcoming version of the Microsoft Windows operating system, code-named "Longhorn." NGSCB employs a unique hardware and software design to enable new kinds of secure computing capabilities to provide enhanced data protection, privacy and system integrity.
NGSCB will transform the PC into a platform that can perform trusted operations spanning multiple computers under a trust policy that can be dynamically created and whose integrity anyone can authenticate.
The technology being developed as part of NGSCB includes new software that will work on a new breed of PC hardware. This new architecture will provide unprecedented capabilities for enabling secure processing on the Microsoft Windows PC platform. In addition, it will preserve the flexibility and extensibility that contributes so much to today's PC ecosystem.
Microsoft is building base-level software components, including a new operating system module called a nexus that will enable secure interaction with applications, peripheral hardware, memory and storage. A nexus-aware PC will be designed to offer four categories of new security features:
Strong process isolation. Users can wall off and hide pages of main memory so that each nexus-aware application can be assured that it is not modified or observed by any other application or even the operating system.
Sealed storage. Information can be stored in such a way that only the application from which data is saved (or a trusted designated application or entity) can open it. With sealed storage, a nexus-aware application or module can mandate that the information be accessible only to itself or to a set of other trusted components that can be identified in a cryptographically secure manner.
Secure path to and from the user. Secure channels allow data to move safely from the keyboard/mouse to nexus-aware applications, and for data to move from nexus-aware applications to a region of the screen.
Attestation. Users have the ability to authenticate software or a combination of software and hardware. With attestation, a piece of code can digitally sign or otherwise attest to a piece of data and thus assure the recipient that the data was constructed by an unforgeable, cryptographically identified trusted software stack.
The Windows technologies that NGSCB introduces — the nexus and the special processes that the nexus commissions, called nexus computing agents (NCAs) — will offer a parallel execution environment to the traditional Windows kernel- and user-mode stacks. NGSCB creates a new environment that runs alongside the operating system, not underneath it.
A key goal in the development of NGSCB is to protect software from software-based attacks in the PC environment. In other words, NGSCB is designed to provide a set of features and services that a software application can use to defend against malicious code that might also be running on the machine, such as viruses running in the main operating system, keyboard sniffers or frame grabbers. This technology is not designed to provide defenses against hardware-based attacks that originate from someone in control of the local machine.
Q: How can I learn more about NGSCB beyond what is in this FAQ?
A: Microsoft will publish additional technical information about NGSCB as it makes progress. To be notified when this information is available, those interested can send e-mail to ngscb_qa@microsoft.com with "subscribe" in the subject line. Microsoft has established this announce-only mailing list to alert subscribers whenever new information has been posted to Microsoft.com.
Q: What's new in NGSCB? What's the difference between NGSCB and Microsoft Windows today?
A: NGSCB extends the Windows operating system to provide a set of new secure computing capabilities. NGSCB will not change anything in Windows, but rather will sit beside with the regular Windows environment. To make NGSCB possible, both the software and the hardware will evolve. On the hardware side, the CPU, chipset, USB I/O and GPU hardware components will be redesigned, and a new component will be added, called the Security Support Component (SSC). On the software side, a new operating system component will be added, called the nexus, along with some associated code to enable the NGSCB environment. Collectively, this software comprises the trusted computing base (TCB) for NGSCB.
Q: What is the "nexus" component of NGSCB?
A: The nexus is a new Windows-based component that will be introduced as part of NGSCB. The nexus is essentially the kernel of an isolated software stack that runs alongside the existing OS software stack. The nexus provides a limited set of APIs and services for applications, including sealed storage and attestation functions. One can think of the nexus as residing in the kernel mode space of the parallel execution environment and nexus computing agents (NCAs, the special processes that the nexus commissions) as residing in the user mode space.
NGSCB is being designed so that a Windows-based PC with the requisite hardware will be able to run different nexuses, although only one nexus at a time will be able to run on a machine. Anyone can write a nexus (licensing issues will be involved and licensing terms have not yet been announced). The user always has the ultimate authority over what nexuses are allowed to run.
Q: What is the "trusted computing base (TCB)" component of NGSCB?
A: The trusted computing base (TCB) includes the nexus and all the associated software and services required to enable the NGSCB environment.
Q: What is the "SSC" component of NGSCB?
A: "SSC" refers to the Security Support Component, a new PC hardware component that will be introduced as part of the NGSCB architecture. The SSC is a hardware module that can perform certain cryptographic operations and securely store cryptographic keys that are used by the nexus and nexus computing agents (NCAs) to provide sealed storage and attestation functions. At a minimum, the SSC provides RSA public-key operations (encryption, decryption, digital signature generation and verification), Advanced Encryption Standard (AES) encryption and decryption, and Secure Hash Algorithm 1 (SHA-1) hash computation. The SSC also contains at least one RSA private key and an AES symmetric key, both of which are private to the SSC and are never exported from the chip.
Q: What is the "TPM"? Is that the same as the SSC?
A: The term "SSC" is generally interchangeable with "TPM" or trusted platform module. The TPM is a secure computing hardware module specified by the Trusted Computing Group, an industry consortium made up of Advanced Micro Devices Inc. (AMD), HP, IBM Corp., Intel Corp., Microsoft and many other companies working together to promote open industry-standard specifications for trusted computing hardware building blocks. The upcoming version of the TPM (version 1.2) is expected to serve as the SSC in the NGSCB architecture.
Q: What is the privacy model associated with NGSCB?
A: Users are always in control of whether nexus-aware technology is enabled on their PC and what nexuses have access to specific functions. The technology being developed as part of NGSCB provides a fine-grained access control model that allows users to specify (by hash) whether a given nexus has the right to invoke a specific security operation. In addition, SSC functions that reveal potentially machine-identifying information, such as the RSA public key, can only be performed once per SSC reset (and the SSC cannot be reset from software; the user must power-cycle the PC).
Q: Is there a trusted root authority? What happens to data if the root is unavailable?
A: There is no requirement for a trusted root authority in either the NGSCB or in the Trusted Platform Module under TCG (see "Next-Generation Secure Computing Base and TCG" below).
Q: Does this technology require an online connection to be used?
A: No.
Q: I have heard that NGSCB will force people to run only Microsoft-approved software.
A: This is simply not true. The nexus-aware security chip (the SSC) and other NGSCB features are not involved in the boot process of the operating system or in its decision to load an application that does not use the nexus. Because the nexus is not involved in the boot process, it cannot block an operating system or drivers or any nexus-unaware PC application from running. Only the user decides what nexus-aware applications get to run. Anyone can write an application to take advantage of new APIs that call to the nexus and related components without notifying Microsoft or getting Microsoft's approval.
It will be possible, of course, to write applications that require access to nexus-aware services in order to run. Such an application could implement access policies that would require some type of cryptographically signed license or certificate before running. However, the application itself would enforce that policy and this would not impact other nexus-aware applications. The nexus and NCAs isolate applications from each other, so it is not possible for an individual nexus-aware application to prevent another one from running.
Q: Does NGSCB spell the end of the smart card industry?
A: To the contrary, by offering stronger protections and security, this technology is very likely to increase the benefits that smart cards offer and increase demand for them.
Smart cards and NGSCB technologies are complementary because each focuses on a different type of authentication problem. Smart cards (and other cryptographic tokens) typically are used to authenticate users: One can be sure the user is present because there is proof that the smart card is present (the card's cryptographic response to a one-time challenge) and, presumably, only the user knows the personal identification number to enable the card. The SSC component of NGSCB architecture is concerned with authenticating the machine and/or a stack of software running on the machine: a machine built to NGSCB principles by itself does not provide the guarantee of presence that a cryptographic token does. (Note that it would be possible to build a digital signature application that was nexus-aware and enforced the same user-present guarantees as a cryptographic token.)
Q: Won't government agencies want a back door?
A: Microsoft will never voluntarily place a back door in any of its products and would fiercely resist any attempt to require back doors in products.
Q: Will NGSCB stop spam or prevent viruses?
A: No. Despite some hype in the media, introducing NGSCB enhancements to the PC ecosystem will not, in and of itself, stop spam or prevent viruses. However, by using NGSCB technology as a foundation, a number of trust and infrastructure models can be built to help combat spam and viruses in new and effective ways.
Let's look at spam first. There has been plenty of research on techniques to automatically reject spam e-mail or restrict the ability of spammers to generate it in the first place. These techniques include the following:
Simply rejecting e-mail that isn't authenticated or digitally signed with a "validated" identity (which would block all anonymous e-mail, including desired anonymous e-mail)
Forcing spammers to perform some nontrivial computation for each message they wish to send
Maintaining per-user lists of approved and nonapproved senders
Scoring every inbound e-mail message using heuristics that look for common characteristics of spam messages
Systems built on NGSCB architecture could certainly be used to improve signing-required or computation-required regimes, compared with what is possible today on conventional hardware (the latter is probably more interesting because NGSCB provides facilities that could allow a sender to prove to a recipient that the sender performed a particular computation within the nexus-aware environment.) Clearly, the realm of possibilities for antispam measures on PCs designed to the NGSCB architecture is a topic deserving of further study.
With respect to viruses, the contribution from the NGSCB architecture is more straightforward. Since the nexus and NCAs do not interfere with the operation of any program running in the regular Windows environment, everything, including the native operating system and viruses, runs there as it does today. Therefore, users are still going to need antivirus monitoring and detection software in Windows as well. However, the NGSCB architecture does provide features that can be used by an antivirus program to help guarantee that it has not been corrupted. The antivirus software can be grounded in such a way that it can bootstrap itself into a protected execution state, something it cannot do today.
Q: What is the difference between NGSCB and per-processor serial numbers?
A: A per-processor serial number (or ID) is a piece of unique state that can be read by any application with access to the processor. The content of the ID is revealed to anyone requesting it, and there is no way to hide the ID or use an indirect identity. More important, users cannot control which software can have access to the per-processor ID. A key design principle of NGSCB is that no processor or user identification is enabled without the user's permission. In addition, nexus-enabled PCs will give users in-depth control of any such use or disclosure. A corollary is that users may choose to run nexus-aware software that hides or renders anonymous any identity (in most circumstances but not all; for example, users will probably always want their bank to be certain of who they are).
To understand the difference between the NGSCB architecture and a per-processor serial number, it is first necessary to look at what unique, per-machine state exists in a PC with NGSCB. One of the components of NGSCB systems is the Security Support Component, a small hardware module with a small amount of persistent, on-chip state. Each SSC includes a unique RSA public/private key pair and a unique AES symmetric key. The AES symmetric key and RSA private key never leave the chip; they are used by the SSC to seal data so that only the SSC can retrieve it and to make signed attestations, respectively. The SSC also will include a digital certificate for the RSA public key, issued by the manufacturer, stating that the private key corresponding to the certified public key is indeed the private key of that SSC.
Because the RSA key pair that ships with each SSC is unique, it could be used to identify the PC motherboard that contains the SSC. To protect against this sort of data aggregation, Microsoft envisions a model in which each nexus generates random RSA key pairs for itself and uses the SSC key only to prove that the random keys were generated by a specific nexus on a NGSCB machine. That is, Microsoft envisions there being a number of non-Microsoft "pseudo-identity providers" that will accept as input an RSA public key signed by an SSC key as well as the digital certificate for that SSC key provided by the manufacturer, and in turn issue a new certificate for the random key. The new certificate would attest that the key is associated with an NGSCB device but would not include any per-machine details or references to the SSC key. These pseudo-identity providers would be trusted third parties (TTPs) that would have the technical means to maintain mappings between the per-machine key and any random keys submitted for certification, but it would be these random keys, certified by the TTP, that would normally be used when communicating with others.
Note that, for some applications, the TTP could be the user; the user (or an organization that the user is part of) could self-certify keys. Organizations or people who trust that user could rely on that intermediate key.
An NGSCB machine will not allow any applications to gain access to the SSC machine key without the user's consent, and Microsoft expects that key to be used only when generating new pseudonyms (random RSA keys) or when migrating sealed secrets from one next-generation device to another.
Q: Are the keys stored on the SSC renewable?
A: No, but neither are they retrievable in any practical way. It is technically conceivable that a dedicated hacker could physically pull the SSC from the motherboard and attack it in a way that would produce the key, provided he or she had access to the hardware. However, this would be an extreme case and even then would only affect the single machine (i.e., it would not be a break once, break everywhere, or "BOBE" attack).
Q: How can anyone be sure that the nexus and related components do exactly what you claim they do?
A: Microsoft will make widely available for review the source code of the trusted computing base so it can be evaluated widely and validated.
Q: What happens in case of a hardware change? Can the data still be accessed?
A: Yes, a nexus-aware application running on one NGSCB machine can encrypt data so that it is accessible on another NGSCB machine. The mechanism for migrating data between the two machines is similar to techniques used today to migrate secret keys among multiple cryptographic hardware accelerators. A similar technique is used to back up encryption keys to provide recovery services in the event of a catastrophic hardware failure.
Q: Which secure nexus-enabled applications has Microsoft planned and when will they be available?
A: It is too early to speculate which Microsoft applications will use nexus functionality or when they will be available. It is easy to imagine scenarios involving secure login, secure data exchange and secure communication solutions.
Q: How could a law enforcement agency access data protected by the NGSCB architecture?
A: Just as with other commercial-grade cryptographic hardware, law enforcement agencies could conceivably "break" the SSC in the hardware of a seized machine to obtain machine secrets. It is important to note, however, that there is no mandatory key escrow planned that would give law enforcement or other entities the ability to obtain keys readily. Keys could be escrowed on the user's behalf with the user's permission, and these could be obtained in the usual manner by law enforcement agencies.
Next-Generation Secure Computing Base and TCG
Q: How is NGSCB related to the Trusted Computing Group (TCG) and the Trusted Computing Platform Alliance (TCPA)?
A: TCG is an industry standards body comprising system manufacturers, device manufacturers, software vendors and others with a stake in enhancing the overall security and trustworthiness of computing devices. TCG announced in April 2003 that it has adopted the technical specifications created by TCPA (TCPA has been discontinued). Microsoft is a founding member of TCG and anticipates that some of the industry standards being developed by the group will be incorporated into NGSCB.
Q: Is NGSCB Microsoft's implementation of the TCG or TCPA specifications?
A: No, NGSCB is not an implementation of the existing specifications developed by TCPA or TCG. The upcoming version of the trusted platform module (TPM 1.2) is expected to work as the security support component in the NGSCB architecture. However, TPM 1.2 is expected to be employed for other secure computing scenarios beyond the NGSCB SSC. (To learn more about TCG technology, those interested can download information and specifications at https://www.trustedcomputinggroup.org.)
Q: In what ways do TCG and the NGSCB architecture differ, and what do they have in common?
A: The NGSCB architecture encompasses a much broader set of functionality than TCG, but both efforts are designed to enable a more secure and trustworthy computing platform.
TCG has defined a set of functional specifications for a component known as the trusted platform module (TPM). The upcoming TPM version 1.2 is expected to work as the security support component (SSC) in NGSCB to provide certain cryptographic and data storage services. In addition, NGSCB involves the following enhancements to further secure the platform:
CPU and memory controller changes to enable strong process isolation (each application has its own execution memory space)
Changes to secure user input (keyboard and mouse) and output (display integrity and confidentiality) to enable a secure path to and from the user
Authenticated booting of nexus
Q: What is the status of Microsoft's engagement in TCG?
A: Microsoft is a founding member of TCG and actively participates in the organization. Microsoft is participating in TCG to advance the level of computing security and privacy. The current TCG specification, TPM 1.1, is not natively supported by Microsoft Windows, nor will it work to enable functionality in an NGSCB machine. TPM 1.1 chips are supported on Microsoft Windows systems via a Cryptographic Service Provider (CSP) provided by the hardware manufacturer, which is written to the Windows Cryptographic Applications Programming Interface (CryptoAPI). Currently, IBM ships PCs that include security-related features based on TPM 1.1.
Microsoft continues to work actively with the other TCG members on a new version of the TPM specification that will meet NGSCB requirements and provide a superset of the current TCG requirements.
Q: Will other software products still run on machines with the TPM?
A: Yes. If the software runs on systems today, it is very likely that it will continue to run on systems with a TPM.
Q: Which versions of TPM are available, which are planned, and how will they support NGSCB architecture?
A: The current version of TPM is 1.1 and is available from three sources: Atmel Corp., Infineon Technologies AG and National Semiconductor Corp. Additional vendors are developing future versions. It is important to note that the TPM 1.1 will support TCG functions defined today; however, systems built with these parts will not support NGSCB.
Microsoft is actively working within TCG to define a new version of the TPM specification that will meet NGSCB requirements and provide a superset of the current TCG requirements.
Q: Is it possible to replace the cryptographic algorithms implemented into a TPM?
A: The TCG specifications define the minimum set of cryptographic algorithms required. TPM makers may choose to support additional cryptographic algorithms.
Q: Is there a restore concept in case of destruction or malfunction of the TPM?
A: Yes. The TPM hardware key typically is not used to store recoverable secrets; however, the TPM key is used to store intermediate keys, which are used to encrypt resources. Just as with any cryptographic keys, there are mechanisms to store and recover them. This is generally done with software; in the NGSCB architecture, the operating system will provide this function.
Q: Will NGSCB technology work with an external TPM?
A: No. Nexus-enabled systems require that the TPM be bound to the system as it is used to provide platform authentication (not user authentication). Portable hardware tokens, such as smart cards, are complementary to the fixed token as they provide means for strong user authentication that can travel with the user. Used together, then, smart card authentication on a nexus-aware system ensures both user authentication and platform authentication.
Next-Generation Secure Computing Base and Digital Rights Management (DRM)
Q: What is the difference between NGSCB and DRM?
A: First, digital rights management refers to a category of software and/or hardware systems that enforce policies that mediate access to digital content or services on machines in the control of entities other than the content publisher or service provider. Once the user of a machine accepts a set of policies, DRM systems are designed to enforce those policies even if the machine owner (or malicious software running on the user's machine) subsequently tries to subvert them.
NGSCB is not DRM. The NGSCB architecture encompasses significant enhancements to the overall PC ecosystem, adding a layer of security that does not exist today. Thus, DRM applications can be developed on systems that are built under the NGSCB architecture. The operating system and hardware changes introduced by NGSCB offer a way to isolate applications (to avoid snooping and modification by other software) and store secrets for them while ensuring that only software trusted by the person granting access to the content or service has access to the enabling secrets. A DRM system can take advantage of this environment to help ensure that content is obtained and used only in accordance with a mutually understood set of rules.
While NGSCB technology enables DRM-style policy enforcement, it also can ensure that user policies are rigorously enforced on a user's machines. In addition, nexus-aware software can provide a mechanism to ensure that user interactions in unsafe environments (such as the Internet) can be safeguarded by software that the user trusts to protect his or her interests and wishes.
The powerful security primitives of NGSCB offer benefits for DRM providers but, as important, they provide benefits for individual users and for service providers. NGSCB technology can ensure that a virus or other malevolent software (even embedded in the operating system) cannot observe or record the encrypted content, whether the content contains a user's personal data, a company's business records or other forms of digital content.
Note that the NGSCB technologies described in this FAQ are also distinctly separate from Microsoft Windows Rights Management Services (RMS), a new security technology that Microsoft announced in February 2003. RMS works with applications to help safeguard sensitive information such as business documents, e-mail messages and line-of-business applications by providing persistent protection that stays with information no matter where it goes. While some elements of RMS are derived from foundation technology Microsoft developed for use with digital media, RMS should not be confused with DRM technologies as they are described in this paper.
Q: Will I still be able to play MP3s on my PC with NGSCB?
A: You will. NGSCB will not interfere with the operation of any program that runs on current PCs. The nexus and nexus computing agents are designed never to impose themselves on processes that do not request their services; nexus-related features must be explicitly requested by a program. So the MP3 player a user has today should by design still work on a next-generation PC tomorrow.
Q: Isn't DRM just for the benefit of big studios and major labels that want to control access to content, restrict its usefulness and get bigger fees? If it is successful, will NGSCB give them unreasonable control over users?
A: Unfortunately, people tend to view rights management systems as being limited to functioning as copy-protection systems for commercial, mass-market movies or music. While such systems can offer a valuable way to facilitate digital content distribution, there are much broader applications for rights management, particularly in the enterprise.
First, it is important to note that the technical mechanisms underlying rights management as employed for digital music or movies also can be employed to ensure the integrity of private information used on a machine outside the control of the information owner (e.g., personally identifiable information such as medical records, corporate information and financial records). In other words, rights management can provide a mechanism by which anyone can impose access control on sensitive information over remote networks and to help ensure that their wishes are enforced.
Second, rights management systems built on the NGSCB architecture can overcome the overly restrictive and sometimes consumer-unfriendly mechanisms that are creeping into closed, captive devices (such as some consumer electronic devices and cell phones), by providing a broad, interoperable platform for content. Unlike closed, captive platforms, PCs built on NGSCB technologies will allow any provider or even individual to build a trustworthy, interoperable mechanism that is not in the exclusive control of a single entity.
Third, unlike "antipiracy" proposals endorsed by some content owners, no nexus-aware application can censor, monitor or disable another nexus-aware application, or in fact any software running on a user's machine, without the user's permission. This central principle of NGSCB — that machine owners are in complete control of their machines and the programs they run — is in stark contrast with some current proposals, which would mandate that all machines incorporate monitoring systems that could arbitrarily disable content or programs. Enhancements to Windows under the NGSCB architecture have no mechanism for filtering content, nor do they provide a mechanism for proactively searching the Internet for "illegal" content.
The NGSCB architecture outlines scalable, granular policy statement and enforcement mechanisms that extend customary file- or resource-protection services, while making these mechanisms interoperable over disparate, disconnected systems.
The NGSCB architecture offers policy enforcement mechanisms that can benefit many parties, but enforcement remains in the control of users. Whether or not they use it in conjunction with rights management systems, people can use such systems to maintain confidentiality, to control the sharing of their documents, to collaborate online with friends, co-workers or colleagues, or to control sensitive operations performed on their machines.
Next-Generation Secure Computing Base and Shared Source Licensing
Q: Can Linux, FreeBSD or another open source operating system run on hardware developed for the NGSCB architecture?
A: Virtually anything that runs on a Windows-based machine today will still run on a NGSCB machine (there are some esoteric exceptions*; a user with a machine that currently runs both Linux and Windows would be able to have that same functionality on an NGSCB machine).
Q: Could Linux, FreeBSD or another open source operating system create a similar trust architecture?
A: From a technology perspective, it will be possible to develop a nexus that interoperates with other operating systems on the hardware of a nexus-aware PC. Much of the NGSCB architecture design is covered by patents, and there will be intellectual property issues to be resolved. It is too early to speculate on how those issues might be addressed.
Next-Generation Secure Computing Base and Unlicensed Software
Q: Some people have claimed that running the Windows operating system with the nexus will enable Microsoft or other parties to detect and remotely delete unlicensed software from my PC. Is this true?
A: This is not true. NGSCB does not include mechanisms that delete or disable any content or file that currently runs on a PC. In fact, the NGSCB architecture is built on the premise that no policy will be imposed that is not approved by the user. Microsoft is firmly opposed to putting "policing functions" into nexus-aware PCs and does not intend to do so. A machine's owner, whether an individual or enterprise, has sole discretion to determine what programs run on the nexus-aware system. Programs that run under nexus-aware systems, just like programs that run under Windows, will do whatever they are allowed to do, based on the security settings on the user's machine. NGSCB not only respects existing user controls, it strengthens them.
As stated earlier, the function of the nexus, NCAs and related components is to make digitally signed statements about code identity and to protect secrets from other nexus-aware applications and regular Windows kernel- and user-mode spaces. Enhancements to the Windows operating system introduced as part of NGSCB do not have any features that make it easier for an application to detect or delete files.
#########
* These exceptions include the following:
Some debuggers may need to be updated to work in the NGSCB architecture environment, but they can still work.
Some special performance tools may need to be updated.
Software that writes directly to TCPA hardware will need to be updated.
Memory scrub routines (at the hardware level) will need attention.
Non-Microsoft crash dump software may need to be updated.
BIOS mode hibernation features will need to be updated.
For more information about NGSCB: Send e-mail to ngscb_qa@microsoft.com