Deeplinkshttps://www.eff.org/ar/rss/updates.xml/trusted-computing
EFF's Deeplinks Blog: Noteworthy news from around the internetarIntel's Management Engine is a security hazard, and users need a way to disable ithttps://www.eff.org/ar/node/95854
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><h3>Intel’s CPUs have another Intel inside.</h3>
<p>Since 2008, most of Intel’s <a href="#update-5-12">chipsets</a> have contained a tiny homunculus computer called the “Management Engine” (ME). The ME is a largely undocumented master controller for your CPU: it works with system firmware during boot and has direct access to system memory, the screen, keyboard, and network. All of the code inside the ME is secret, signed, and tightly controlled by Intel. Last week, vulnerabilities in the Active Management (AMT) module in some Management Engines have caused lots of machines with Intel CPUs to be disastrously vulnerable to remote and local attackers. While AMT can be disabled, there is presently no way to disable or limit the Management Engine in general. Intel urgently needs to provide one.</p>
<p>This post will describe the nature of the vulnerabilities (thanks to Matthew Garrett for <a href="https://mjg59.dreamwidth.org/48429.html">documenting them well</a>), and the potential for similar bugs in the future. EFF believes that Intel needs to provide a minimum level of transparency and user control of the Management Engines inside our computers, in order to prevent this cybersecurity disaster from recurring. Unless that happens, we are concerned that it may not be appropriate to use Intel CPUs in many kinds of critical infrastructure systems.</p>
<h3>What is AMT? How is it vulnerable?</h3>
<p>On many Intel chips, the Management Engine is shipped with the AMT module installed. It is intended to allow system administrators to remotely control the machines used by an organization and its employees. A vulnerability <a href="https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&amp;languageid=en-fr">announced</a> on May 1 allows an attacker to bypass password authentication for this remote management module, meaning that in many situations remote attackers can acquire the same capabilities as an organization’s IT team, if active management was enabled and provisioned.<a class="see-footnote" id="footnoteref1_jbwom4c" title="A second consequence of this vulnerability allowed local, non-administrator users of Windows systems to provision AMT, if a Windows component called Local Manageability Service (LMS) is installed (whether LMS is installed is typically up to the hardware manufacturer — for instance Lenovo would decide whether or not to include LMS on a Thinkpad by default). This second consequence allows non-admin users or compromised accounts to take complete control of those machines by provisioning AMT with settings of their choice." href="#footnote1_jbwom4c">1</a></p>
<p>Once they have AMT access, attackers can interact with the <a href="https://en.wikipedia.org/wiki/Virtual_Network_Computing">screen</a> or <a href="https://en.wikipedia.org/wiki/System_console">console</a> as if the user were doing so themselves. Attackers can also boot arbitrary OSes, install a new OS, and (with some work) steal disk encryption passwords.<a class="see-footnote" id="footnoteref2_e05ld2s" title="AMT access is not the same as running arbitrary ME code, so attackers can’t access system memory directly; they have to use the console, VNC, or boot OS images to accomplish their goals." href="#footnote2_e05ld2s">2</a></p>
<p>Not every machine is susceptible to the attack. For it to work, AMT has to have been both <em>enabled</em> and <em>provisioned</em> (commonly AMT is enabled but not provisioned by default). Once provisioned, AMT has a password set, and is listening for network packets and will control the system in response to those.<a class="see-footnote" id="footnoteref3_bptqkt2" title="If provisioned, AMT listens on ports 16992 and 16993. Often this would only be on a physical Ethernet connection, but provisioning can also enable AMT over WiFi (once an OS is running, AMT over WiFi requires OS support)." href="#footnote3_bptqkt2">3</a> It can be provisioned by default if vendors used a feature called <a href="https://software.intel.com/en-us/articles/remote-configuration-for-intel-amt">“Remote Configuration” with OEM Setup</a>, by a user with administrative access, interactively or with a USB stick during system boot, or (via the LMS vulnerability) by unprivileged users on Windows systems with LMS. Macs have MEs, but don’t ship with AMT at all. The password protection is crucial for machines with AMT provisioned, but this week’s vulnerability allowed it to be bypassed.</p>
<h3>How can users protect themselves?</h3>
<p>Many organizations will need to take steps to protect themselves by ensuring that AMT is disabled in their BIOS and LMS is not installed, or by updating Intel firmware.<br />
Unfortunately, even if AMT is currently disabled, that doesn’t mean an attack was never possible<span>—</span>an attacker might have disabled AMT after concluding the attack, to close the door on their way out.</p>
<p>But troublingly, AMT is only one of many services/modules that come preinstalled on Management Engines. The best recommendation we can make for addressing this vulnerability today is to disable that specific AMT module, because Intel doesn’t provide any way to generally limit the power of the ME. But vulnerabilities in any of the other modules could be as bad, if not worse, for security. Some of the <a href="https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub/17">other modules</a> include <a href="https://www-ssl.intel.com/content/www/us/en/architecture-and-technology/identity-protection/identity-protection-technology-general.html">hardware-based authentication</a> code and a system for <a href="https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub/17">location tracking and remote wiping of laptops</a> for anti-theft purposes. While these may be useful to some people, it should be up to hardware owners to decide if this code will be installed in their computers or not. Perhaps most alarmingly, there is also <a href="https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub/17">reportedly</a> a <a href="https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/676149">DRM module</a> that is <a href="https://www.eff.org/issues/drm">actively working against the user’s interests</a>, and should never be installed in an ME by default.</p>
<p>For expert users on machines without Verified Boot, a Github project called <a href="https://github.com/corna/me_cleaner">ME cleaner</a> exists and can be used to disable a Management Engine. But be warned: using this tool has the potential to brick hardware, and interested parties should exercise caution before attempting to protect their systems. A real solution is going to require assistance from Intel.</p>
<h3>What Intel needs to do fix this mess</h3>
<p>Users need the freedom to choose what they want running on their system, and the ability to remove code that might contain vulnerabilities. Because the Management Engine only runs code modules signed by Intel, this means having a way to disable the ME or reflash it with minimal, auditable firmware. While Intel may put a lot of effort into hunting for security bugs, vulnerabilities will inevitably exist, and having them lurking in a highly privileged, low level component with no OS visibility or reliable logging is a nightmare for defensive cybersecurity. The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility.</p>
<p>What would be best for users and for the public’s ability to control machines that they have purchased would be for Intel to provide official support for reducing the attack surface to limit the potential harm of the ME.</p>
<p>So we call upon Intel to:</p>
<ul><li>Provide clear documentation for the software modules that are preinstalled on various Management Engines. What <a href="https://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface">HECI</a> commands provide a full list of the installed modules/services? What are the interfaces to those services?</li>
<li>Provide a way for their customers to audit ME code for vulnerabilities. That is presently impossible because the code is kept secret.</li>
<li>Offer a supported way to disable the ME. If that’s literally impossible, users should be able to flash an absolutely minimal, community-auditable ME firmware image.</li>
<li>On systems where the ME is an essential requirement for other security features that are important to some users (like Boot Guard), offer an additional option of a near-minimal, community-auditable ME firmware image that performs these security functions, and nothing else. Or alternatively, a supported way to build and flash firmware images where the user can inspect and control which services/modules are present, in order to manage security risks from those modules.</li>
</ul><p>Until Intel takes these steps, we have reason to fear that the undocumented master controller inside our Intel chips could continue to be a source of serious vulnerabilities in personal computers, servers, and critical cybersecurity and physical infrastructure. Intel needs to act quickly to provide the community with an auditable solution to these threats.</p>
<p><em><b id="update-5-12">Correction 2017-05-12:</b> Intel has contacted us with two corrections to the details of this post. (1) Management Engines are not physically located on the CPU die itself, but in <a href="https://hardenedlinux.github.io/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html#00-me-management-engine">other parts of Intel's chipsets</a>; (2) the LMS-based local privilege escalation was a second consequence of the first code vulnerability, rather than a second vulnerability or bug of its own. We have accordingly edited the language of this post in a couple of places, but do not believe these updates affect its conclusions.</em></p>
<ul class="footnotes"><li class="footnote" id="footnote1_jbwom4c"><a class="footnote-label" href="#footnoteref1_jbwom4c">1.</a> A second <a href="#update-5-12">consequence of this vulnerability</a> allowed local, non-administrator users of Windows systems to provision AMT, if a Windows component called Local Manageability Service (LMS) is installed (whether LMS is installed is typically up to the hardware manufacturer — for instance Lenovo would decide whether or not to include LMS on a Thinkpad by default). This second consequence allows non-admin users or compromised accounts to take complete control of those machines by provisioning AMT with settings of their choice.</li>
<li class="footnote" id="footnote2_e05ld2s"><a class="footnote-label" href="#footnoteref2_e05ld2s">2.</a> AMT access is not the same as running arbitrary ME code, so attackers can’t access system memory directly; they have to use the console, VNC, or boot OS images to accomplish their goals.</li>
<li class="footnote" id="footnote3_bptqkt2"><a class="footnote-label" href="#footnoteref3_bptqkt2">3.</a> If provisioned, AMT listens on ports 16992 and 16993. Often this would only be on a physical Ethernet connection, but provisioning can also enable AMT over WiFi (once an OS is running, AMT over WiFi requires OS support).</li>
</ul></div></div></div>Mon, 08 May 2017 19:32:57 +000095854 at https://www.eff.orgDRMSecurityDefend Your Right to Repair!Trusted ComputingSecurity EducationErica PortnoyPeter Eckersley Why Would MS Do Hollywood's Bidding?https://www.eff.org/ar/deeplinks/2005/08/why-would-ms-do-hollywoods-bidding
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><p>You might be asking yourself that question, if you've been following our series on Microsoft's <a href="http://www.eff.org/deeplinks/archives/003882.php">trusted computing and DRM strategies.</a> No Microsoft customer wants DRM-crippled operating systems, hardware, and video content.</p>
<p>Hollywood, on the other hand, wants ubiquitous DRM. And, wielding DRM and the <a href="http://www.eff.org/IP/DMCA/">DMCA</a>, major movie studios can shut Microsoft out of the lucrative digital video market if it doesn't play ball. In that game, consumers will inevitably lose.</p>
<p>Hollywood is saying, loudly and to anyone who will listen, "unless we get content protection that satisfies us, our next-gen high-definition video will not be on your platform." Since there are only a handful of major studios who control 90%+ of commercially important film and TV content, this kind of cartel threat is relatively credible.</p>
<p>In the past, this would have been an empty threat, since someone could just build a device to play their content, whether they liked it or not. Not so since 1998, thanks to the DMCA. Now, if Hollywood encrypts its content, tech vendors need to get permission before they can build a device to play it.</p>
<p>Let's review what's happened since 1998 thanks to that big legal shift:</p>
<p>(Read on for more after the jump.)</p>
<p>
1. DVDs are encrypted, which means that you have to sign a license before you can build a DVD player or recorder. So Hollywood gets veto power over new DVD features, thanks to the DVD-CCA license. Companies that build cool DVD products get sued (see, e.g., <a href="http://www.eff.org/minilinks/archives/week_2005_02_27.php#003390">Kaleidescape</a>).</p>
<p>2. Cable <a href="http://www.eff.org/IP/Video/HDTV/?f=pnp.html">added DRM</a> to its set-top boxes and CableCard architectures, for fear that Hollywood would otherwise favor satellite (which, as the minority player, was happy to court Hollywood) with "premium" content.</p>
<p>3. Blu-ray and HD-DVD are now in <a href="http://www.freedom-to-tinker.com/?p=883">a DRM bidding war</a> to please Hollywood, as demonstrated by the Blu-Ray DRM features announced this week.</p>
<p>4. Microsoft is now <a href="http://www.eff.org/deeplinks/archives/003806.php">adding</a> <a href="http://www.eff.org/deeplinks/archives/003807.php">DRM</a> to Windows, for fear that otherwise Hollywood will lock them out of next-gen HD Hollywood content, thereby slamming the door on convergence home theater PC products built on Windows Media Center Edition (MCE) technologies. After all, the traditional consumer electronics companies would be quite happy to have the next generation DVD products play only on purpose-built Blu-Ray boxes.</p>
<p>The computer industry in general is actually quite afraid of being left out of the Hollywood party -- I remember hearing stories about how DVD almost never made it to PCs, because the computer industry was so late to the negotiating table. After all, from Hollywood's point of view, the mainstream market for DVDs is playback on DVD players in your living room. The PC home theater stuff is niche today, untested tomorrow, at best. For the computer guys, on the other hand, this convergence stuff is a critical part of their effort to convince you that you actually need to buy new PCs and displays.</p>
<p>In sum, it's classical economics -- on one side you have a supplier cartel with market power (Hollywood), on the other side you have several competing technology platform providers (Microsoft, the major CE companies, etc) each eager to get picked by the cartel (and thereby gain competitive advantage over those not picked).</p>
<p>Notably, neither Microsoft nor Hollywood are betting on the DRM being uncrackable or preventing widespread P2P file-sharing. In fact, Microsoft's own trusted computing engineers admitted in 2002 that DRM is no silver bullet for digital "darknet" sharing. But that's beside the point from Hollywood's point of view. Hollywood's chief interest in DRM is getting control over disruptive technologies, by forcing innovators to sign licenses (i.e., beg permission) before they can build products that make use of Hollywood content. Meanwhile, Microsoft is betting that giving Hollywood a say in the future of video will pay off in favored access to next-gen Hollywood content, which will, in turn, drive consumers to buy Windows machines and applications.</p>
<p>Reasonable minds certainly can differ on whether this is a good bet for Microsoft. What you can't deny is that consumers lose in the bargain, as they get stuck with less useful, DRM-laden devices today, and a less innovative marketplace tomorrow. After all, if Sony had to ask for a license before building the Betamax VCR in 1976, the history of home video would look very different today.</p>
</div></div></div>Fri, 12 Aug 2005 18:33:04 +000059277 at https://www.eff.orgTrusted ComputingFred von Lohmann Your General-Purpose PC --> Hollywood-Approved Entertainment Appliancehttps://www.eff.org/ar/deeplinks/2005/08/your-general-purpose-pc-hollywood-approved-entertainment-appliance
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><p>Edward Felten has an <a href="http://www.freedom-to-tinker.com/?p=882"> extraordinary post</a> detailing how Microsoft is giving Hollywood explicit veto power over the functionality of the upcoming Windows Vista operating system (formerly known as Longhorn). How explicit? Check out this excerpt from the Microsoft <a href="http://download.microsoft.com/download/5/D/6/5D6EAF2B-7DDF-476B-93DC-7CF0072878E6/output_protect.doc">white paper</a>:</p>
<blockquote><p>"Other companies are free to invent their own [encryption for outputting video content] ... but security considerations mean that there is a high bar to meet before a new cipher can be approved for use....</p>
<p>The evidence must be presented to Hollywood and other content owners, and they must agree that it provides the required level of security. Written proof from at least three of the major Hollywood studios is required."</p></blockquote>
<p>With its entertainment industry accomplices, Microsoft is turning your general-purpose computer into a toaster -- a content-vending appliance that obeys copyright holders, not you. As Felten <a href="http://www.freedom-to-tinker.com/?p=882">explains</a>, your PC will cost more and do less. </p>
<p>It will also make criminals out of more and more legitimate technology tinkerers and average users. To modify practically any part of your PC and use the software or hardware of your choice, you'll have to circumvent DRM in ways that may violate the <a href="http://www.eff.org/IP/DMCA/">DMCA</a>. </p>
<p>Meanwhile, Microsoft's new DRM will <a href="http://crypto.stanford.edu/DRM2002/darknet5.doc">do nothing</a> to prevent widespread infringing distribution of copyrighted content -- the illegal activity that the restrictions are supposed to target.</p>
<p>The white paper discusses only a handful of ways Microsoft intends to make DRM ubiquitous. If you haven't already, check out Staff Technologist Seth Schoen's recent four-part series on Microsoft's security and lockware strategy, exploring the dirty details of the latest developments and their impact on your ability to control your own computer, create or use interoperable products, exercise your fair-use rights, and protect your privacy and computer security:</p>
<p><a href="http://www.eff.org/deeplinks/archives/003804.php">Part 1: "Microsoft Trusted Computing Updates"</a></p>
<p><a href="http://www.eff.org/deeplinks/archives/003805.php">Part 2: "The Dangers of Device Authentication"</a></p>
<p><a href="http://www.eff.org/deeplinks/archives/003806.php">Part 3: "Protected Media Path, Component Revocation, Windows Driver Lockdown"</a></p>
<p><a href="http://www.eff.org/deeplinks/archives/003807.php">Part 4: "Microsoft Sells Out the Public on CGMS-A"</a></p>
</div></div></div>Tue, 09 Aug 2005 18:44:25 +000059274 at https://www.eff.orgTrusted ComputingDerek Slater Microsoft Sells Out the Public on CGMS-Ahttps://www.eff.org/ar/deeplinks/2005/07/microsoft-sells-out-public-cgms
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><p>Staff Technologist <a href="http://www.eff.org/about/staff/#seth_schoen">Seth Schoen</a>, EFF's resident expert on <a href="http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php">trusted computing</a>, recently attended this year's <a href="http://www.microsoft.com/whdc/winhec/default.mspx">Windows Hardware Engineering Conference</a> (WinHEC). This is the final post in a four-part series in which Schoen provides detailed updates on the status of Microsoft's security and lockware strategies for Windows. The outcome of these strategies will affect to what degree people using the platform and "trusted" PCs can maintain a <a href="http://www.linuxjournal.com/article/7055">desirable level of control</a> over their own computers. Previous posts can be found <a href="http://www.eff.org/deeplinks/archives/003806.php">here</a>, <a href="http://www.eff.org/deeplinks/archives/003805.php">here</a>, and <a href="http://www.eff.org/deeplinks/archives/003804.php">here</a>.</p>
<p>*****</p>
<p>Although the <a href="http://www.eff.org/IP/DMCA/">Digital Millennium Copyright Act</a> gave the public <a href="http://www.eff.org/IP/DMCA/?f=unintended_consequences.html">a raw deal</a>, its reach is not unlimited. The DMCA's scope is expressly limited by the so-called "no mandate" clause, which establishes that technologies that deal with unencrypted, open standard media formats are not restricted by the DMCA. These technologies are unregulated even if the entertainment industries dislike them and even if they do not obey those industries' preferences for restricting users. Absent additional legislation, the copyright holders have no right to control general-purpose technologies -- like computers, sound cards, or software -- that deal only with open standards. That's why the Motion Picture Association of America has long sought new "technology mandate" legislation to go beyond the DMCA: to impose the <a href="http://www.eff.org/IP/Video/HDTV/">broadcast flag</a>, to <a href="http://www.eff.org/IP/Video/ardg_eff_comments.php">"close the analog hole,"</a> and to regulate file-sharing software. Without such legislation, MPAA argues, the public will continue to have access to at least some avenues for making unauthorized uses.</p>
<p>Or will it? What if technology companies collaborate with Hollywood in locking up open standards, even without any legal obligation to do so? This prospect is looking increasingly plausible as Microsoft moves closer to supporting the Copy Generation Management System for Analog (CGMS-A). CGMS-A is an industry standard for marking video programming with metadata about the copyright holder's or broadcaster's preferences for whether and how a work may be recorded. The DMCA expressly provides that devices do not have to act upon or enforce such preferences; complying with CGMS-A metadata is a favor to Hollywood, not the law.</p>
<p>(Read on for more after the jump.)</p>
<p>
If a recording device -- including a video capture card in a PC -- is not specifically built with extra logic to detect CGMS-A, it won't even know whether CGMS-A markings are present. (CGMS-A is literally carried alongside closed-caption data -- a deliberate choice in order to deter devices from simply discarding that part of the video signal. Just as a video recorder without a closed-caption decoder would record and play back a recording without detecting or displaying captioning, a recorder without special CGMS-A decoders will record and play back without regard to the CGMS-A markings.)</p>
<p>For years, Hollywood has responded to criticism of the effects of digital rights management (DRM) on fair use by suggesting that the public can still use analog outputs to make (possibly lower-quality) copies of works for fair use purposes. Because of the prospect of using analog outputs in this way, say studios, lawful personal copying is not completely eliminated by DRM. Even as they made this argument, however, the studios pursued a campaign to restrict such recording by characterizing it as a "loophole" -- the so-called "analog hole" or "analog reconversation problem." The same recording techniques that movie studios hailed as the protection for fair use were also stigmatized as an intolerable escape from the supposedly perfectly controlled world of DRM.</p>
<p>Just as a sound card can take its input from a phonograph player or CD player, allowing computers to record sounds from the outside world, a computer video card can take input from a TV tuner, set-top box, VCR, or other video device, allowing the computer to record and process video. Both of these devices are unquestionably lawful, and both are now standard equipment in desktop PCs. But entertainment industries have attacked both as threatening DRM by allowing the creation of unencrypted recordings through the "analog hole." So far, Congress has not been eager to act on this concern. Yet entertainment companies are pursuing an astonishingly effective campaign to persuade technology firms to stop making and selling lawful recording devices.</p>
<p>CGMS-A compliance is one of Hollywood's top priorities. A lack of transparency in the copyright industry's negotiations with technology companies makes it unclear precisely what sorts of threats and incentives are winning the technologists over. Yet these negotiations appear to be accomplishing what Congress declined to do: making devices that obey CGMS-A ubiquitous, arranging for recording equipment to comply with the studios' and broadcasters' copying policy preferences, even to the point of refusing to record certain programming at all. Once again, this outcome is not the law; it is simply the technologists' decision to side with the studios against end users.</p>
<p>Microsoft's capitulation on CGMS-A is only the most recent in a string of Hollywood successes. Indeed, so common is voluntary CGMS-A compliance becoming that studios have taken to openly stigmatizing recording devices that do not implement CGMS-A as though Congress had already banned them. This is despite the fact that CGMS-A compliance -- just like broadcast flag compliance in the digital television context -- requires extra expense and engineering complexity, and produces devices with strictly less functionality for consumers.</p>
<p>Microsoft's collaboration on CGMS-A comes in the form of the <a href="http://www.microsoft.com/whdc/device/stream/BDA_protect.mspx">Protected Broadcast Driver Architecture (PBDA)</a> in the forthcoming Windows Longhorn and other Windows operating systems. PBDA also includes support for applying DRM restrictions to programming received from conditional access systems such as premium cable. Prior to the <a href="http://www.eff.org/deeplinks/archives/003555.php">recent court decision</a> striking down the broadcast flag rule, PBDA also included mechanisms for broadcast flag compliance. (Microsoft has not indicated whether broadcast flag compliance will be removed from Windows Longhorn now that the law does not require it. There is therefore a possibility that, as with CGMS-A, Longhorn will also obey the broadcast flag restrictions even though it is not legally obliged to do so.)</p>
<p>PBDA is used to apply DRM restrictions to video programming received from a broadcast or analog video input device. It supports a fairly flexible mechanism to allow Microsoft, in negotiations with broadcasters or other parties, to define sets of Windows Media 10 DRM restrictions that correspond to particular kinds of restrictions requested by a broadcaster. In the case of CGMS-A, PBDA will encrypt the (originally unencrypted) video stream from a capture device with Windows Media 10 DRM if the CGMS-A markings in the video indicate that copying restrictions were requested. If an analog video signal is marked Copy Never, PBDA can prevent Windows from recording it at all.</p>
<p>The use of PBDA requires video hardware manufacturers to meet certain technical requirements. For example, their hardware must provide Windows with the appropriate parts of the video signal to allow PBDA to look for flags that indicate which restrictions were requested.</p>
<p>Although it is still possible to write Windows drivers for video capture equipment that ignores CGMS-A entirely, Microsoft is taking steps to prevent such arrangements from becoming popular or profitable in the marketplace. It will use licensing and compatibility logo programs to ensure that hardware and software most commonly bundled with Windows -- including products built around the popular Windows Media Center Edition -- are PBDA-compatible. Manufacturers suggest that this will tend to further marginalize equipment and Windows software configurations that ignore CGMS-A, since it is immensely difficult to turn a profit in the Windows multimedia market without participating in Microsoft's compatibility and logo-branding programs. </p>
<p>Therefore, video recording equipment and drivers that simply record video inputs, without decoding them and without applying DRM restrictions, are likely to become increasingly limited to the hobbyist and niche markets. Apart from its impact on the fair use rights of the general public and on third-party PVR software for Windows, this could make it ever easier for movie studios to stigmatize non-CGMS-A aware equipment as outside a perceived industry consensus and therefore somehow bad.</p>
<p>Microsoft ought to be building media products that let people use multimedia in all the ways that copyright law permits -- or, at the least, not standing in the way of others who want to do so.</p>
</div></div></div>Wed, 27 Jul 2005 11:18:22 +000059258 at https://www.eff.orgFair UseDRMAnalog HoleTrusted ComputingDerek Slater Protected Media Path, Component Revocation, Windows Driver Lockdownhttps://www.eff.org/ar/deeplinks/2005/07/protected-media-path-component-revocation-windows-driver-lockdown
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><p>Staff Technologist <a href="http://www.eff.org/about/staff/#seth_schoen">Seth Schoen</a>, EFF's resident expert on <a href="http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php">trusted computing</a>, recently attended this year's <a href="http://www.microsoft.com/whdc/winhec/default.mspx">Windows Hardware Engineering Conference</a> (WinHEC). This is the third of a four-part series in which Schoen provides detailed updates on the status of Microsoft's security and lockware strategies for Windows. The outcome of these strategies will affect to what degree people using the platform and "trusted" PCs can maintain a <a href="http://www.linuxjournal.com/article/7055">desirable level of control</a> over their own computers. The first two posts can be found <a href="http://www.eff.org/deeplinks/archives/003804.php">here</a> and <a href="http://www.eff.org/deeplinks/archives/003805.php">here</a>.</p>
<p>*****</p>
<p>In the near future, when you try to install software to time-shift your favorite Real Audio webcast, your PC might disable all media player applications. Until you remove the software, your PC will remain crippled. Or perhaps you want to watch a downloaded movie on a wide-screen TV, but your PC might turn off its video card's analog output.</p>
<p>Welcome to the world of Windows Longhorn (now known as <a href="http://www.microsoft.com/windowsvista/default.mspx">Vista</a>) and the Protected Media Path, where Microsoft, copyright holders, and DRM licensors may grant or revoke permission to use your own computer and digital media. </p>
<p>(Read on after the jump.)</p>
<p>
According to announcements at 2005 <a href="http://www.microsoft.com/whdc/winhec/default.mspx"> Windows Hardware Engineering Conference</a> (WinHEC), Microsoft's Windows Longhorn will go to great lengths to prevent users from tinkering with their own software environments. The proximate cause of the new restrictions is a scheme called Protected Media Path (PMP), which helps Longhorn make DRM for audio and video significantly stronger.</p>
<p>PMP has its roots in an earlier Microsoft initiative called <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmrm10/htm/understandingsecureaudiopathbyprotectingdigitalmed.asp">Secure Audio Path (SAP)</a>. PMP works with video as well as audio, is more sophisticated than SAP, and calls for significantly further-reaching changes at the operating system level.</p>
<p>WinHEC participants described Microsoft's PMP work as largely motivated by an effort to induce the major US movie studios to authorize next-generation DVDs to be played on Windows. DRM engineers frequently referred to "next-generation content" and to the risk that the Windows PC platform would be cut off entirely from (lawful) access to it unless much of the industry meets Hollywood's demands. There's much to doubt in this story, but Microsoft and its business partners are playing along with it.</p>
<p>PMP includes several phases and features which Microsoft plans to introduce over time. One such feature is COPP, which allows applications to selectively disable the use of particular video cards or particular outputs on a video card. (For example, an application could refuse to output to a DVI output without HDCP encryption, or to an analog VGA output, or to a YPbPr component video output.) In the consumer electronics world, this functionality is known as "selectable output control"; it gives software and encrypted media increased power to intentionally break compatibility in obsolete already-purchased equipment. If video card manufacturers fail to implement selectable output control, their video cards will not receive Microsoft compatibility logo approval, cannot be used in Media Center Edition PCs, cannot be bundled with PCs whose manufacturers receive certain discounts and incentives from Microsoft, and may be intentionally unsupported by DRM applications running on Windows Lonhorn.</p>
<p>PMP will also eventually provide a means of requiring authentication of output devices and encryption of communication between software and an authenticated output device. (See our separate article on device authentication for more information.)</p>
<p>Finally, PMP will create a kernel-enforced construct called a Protected Environment (PE) in which particular software modules, including drivers and other code, that are trusted by particular entertainment companies can run and enforce DRM restrictions. The construction and protection of the PE requires the further-reaching changes to the way that software, especially drivers, is developed for the Windows platform; it also gives Microsoft a new kind of power over Windows software developers.</p>
<p>Components that are loaded into the PE by the Windows kernel must be signed and authenticated; software developers must also have produced them pursuant to a license with Microsoft, and their developers must have committed to follow certain policies that Microsoft promulgates. Publishers can associate policies with their published works indicating which components they trust, and the PE will enforce these policies.</p>
<p>Perhaps most significantly, the PE will be subject to a "global revocation list" maintained by Microsoft and distributed through Windows Update and possibly other channels. Microsoft will maintain and sign the revocation list, and its updates will have ever-increasing version numbers. Works meant to be played back through PMP can require a particular minimum revocation list version number; the PE will not allow a restricted work to be played at all unless the computer has loaded a revocation list at least as recent as the one specified by the work. If a software component appears on the revocation list, the PE will not load it, or will warn applications that a revoked software component has been loaded.</p>
<p>Drivers that run in kernel mode will fall into three categories. First, some drivers are meant to participate in the PE; these drivers must be signed and created subject to a license with Microsoft, and must follow certain policies and coding practices that Microsoft promulgates. Their code must be submitted to Microsoft for review, and Microsoft has the right to revoke them if it discovers a violation of its policies and standards. Under certain conditions, Microsoft can even fine licensees who write participating drivers that are subsequently revoked.</p>
<p>Second, some drivers are not meant to participate in the PE. Even though these drivers are unrelated to DRM functions or output functions, and even though Microsoft does not author them, Microsoft demands that the drivers' authors sign them, and Microsoft retains the ability to revoke these third-party drivers. For example, if Microsoft decides that a third-party mouse drive or third-party USB storage device driver does not meet its security standards (for example, if the driver ever allows user programs such as a debugger to gain kernel-level privilege), Microsoft can add the third-party driver to the revocation list. If Microsoft revokes such a driver, the PE cannot be established on a system where the driver is loaded. Thus, users who want to use applications that require the PE to be established have a powerful incentive to stop using the revoked driver version.</p>
<p>Finally, some authors do not sign their drivers (as in the status quo). Microsoft strongly disapproves of this practice, and all such unsigned drivers will be treated as revoked by default; that is, the PE cannot be established if such drivers are present.</p>
<p>The result of all of this is that all third-party developers of device drivers that need to run with kernel privilege on Windows will be need to obey Microsoft's policies about not implementing features that might undermine the PE. (This means that some existing drivers that intentionally give the authorized user privileged access to the system will be considered insecure.) If they do not obey these policies, they can be revoked and they will no longer be usable on systems where a user needs to establish the PE. Microsoft has not provided details of the user interface that will inform the user about revoked drivers or software components, but it's a safe bet that it will place the blame on the developers of the revoked software -- not on the Protected Media Path system, Microsoft, or the movie studios.</p>
<p>One important distinction between participating and non-participating drivers is that participating drivers (that are meant to run in the PE) can only be loaded if Microsoft has pre-approved them. By contrast, non-participating drivers (that are not meant to run in the PE but that nonetheless have kernel privilege) can be loaded, even in the presence of the PE, unless Microsoft has affirmatively revoked them. As we explain below, this means that -- in the PMP system as currently described -- people can develop and use signed drivers that violate the PMP's security policies, as long as those drivers never come to Microsoft's attention.</p>
<p>In Windows Longhorn, PMP will not use trusted computing hardware features to prevent reverse engineering; therefore, traditional software attacks will continue to be effective, although they may be more costly and annoying to implement than in the past because of increased efforts to support DRM at lower layers of the operating system, to make more extensive use of code signing, and to obfuscate binary code to slow down reverse engineering. Future versions of<br />
Windows may begin to use trusted computing hardware to prevent reverse engineering and modification of the PMP code. This application of trusted computing is not in users' interests, but it may be difficult for users to co-ordinate resistance to it because of the large number of companies supporting it. (Microsoft has not announced whether it will use trusted computing as part of its Windows Product Activation scheme, but it might be possible to require the use of a TPM-enabled platform as part of the Windows activation process. If Microsoft does so, it would be difficult to opt out of the use of the TPM while continuing to use Windows; the product activation step could also be used to bootstrap the enforcement of other DRM policies.)</p>
<p>What will be the consequences of the implementation of PMP? It's instructive to compare PMP to the DRM system that is one of the reasons for its creation -- the AACS system, which will be included on next-generation DVDs as a replacement for today's CSS. Ed Felten recently<br /><a href="http://www.freedom-to-tinker.com/?p=800">explained</a> why AACS is likely to harm innovation and competition, without doing much to deter copyright infringement. AACS includes an elaborate scheme to allow copyright industries to revoke unauthorized playback software or equipment -- if it's distributed to the public. It can, however, be used in private:</p>
<blockquote><p>
If somebody, somewhere makes his own player using a reverse-engineered DeviceID, and doesn't release that player to the public, then he will be able to use it with impunity to play or rip discs. His DeviceID can only be blacklisted if the licensing authority learns what it is, and the authority can't do that without getting a copy of the player. Even if a player is released to the public, it will still make all existing discs rippable.
</p></blockquote>
<p>The PMP PE and its revocation list have precisely the same structural problem. They give Microsoft -- and the movie studios -- tremendous power over what kind of software can be run in the kernel of a Windows machine. For the first time, Microsoft can directly impose costs on users who use software that Microsoft dislikes by breaking those users' media players unless the users uninstall the disapproved software. Yet copyright infringement is still easy. The infringers just need to write and sign device drivers that break the PMP PE by deliberately violating Microsoft's policies. Then they need to refrain from publishing those drivers. (Even if Microsoft tries to scrutinize third-party drivers, it should be straightforward to introduce an intentional "bug" in a driver, claim it's an internal development version, and never release it to the public. This might be possible even in a world where Microsoft reviewed all Windows driver <a href="http://www.brainhz.com/underhanded/">source code</a>, a level of supervision far more intrusive than what Microsoft has announced at WinHEC.) The infringers can continue to attack DRM in private and publish decrypted copies of movies; even if their drivers are leaked and Microsoft revokes them, they will still work for decrypting movies published prior to the date of revocation. The analogy between the effects of AACS and the effects of PMP is thus fairly direct.</p>
<p>Like AACS, the implementation of PMP would limit what kind of media technology is generally available to the public. Like AACS, it would help restrict the feature set that published or generally-available products could implement. Like AACS, it will give more power to those who control the keys, and more leverage over unrelated areas of technology. And like AACS, it will not stop copyright infringement.</p>
</div></div></div>Mon, 25 Jul 2005 20:55:53 +000059253 at https://www.eff.orgFair UseDRMAnalog HoleTrusted ComputingDerek Slater The Dangers of Device Authenticationhttps://www.eff.org/ar/deeplinks/2005/07/dangers-device-authentication
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><p>Staff Technologist <a href="http://www.eff.org/about/staff/#seth_schoen">Seth Schoen</a>, EFF's resident expert on <a href="http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php">trusted computing</a>, recently attended this year's <a href="http://www.microsoft.com/whdc/winhec/default.mspx">Windows Hardware Engineering Conference</a> (WinHEC). This is the second of a four-part series in which Schoen provides detailed updates on the status of Microsoft's security and lockware strategies for Windows. The outcome of these strategies will affect to what degree people using the platform and "trusted" PCs can maintain a <a href="http://www.linuxjournal.com/article/7055">desirable level of control</a> over their own computers. The first post in the series can be found <a href="http://www.eff.org/deeplinks/archives/003804.php">here.</a></p>
<p>*****</p>
<p>It has been difficult for most software that communicates with peripherals on the PC platform to answer two questions confidently:</p>
<p>(1) Am I talking to the particular make and model of peripheral I think I am?</p>
<p>(2) Am I talking to genuine physical hardware, rather than software that mimics its functionality?</p>
<p>(There are also other related questions that are somewhat more obscure; for example, "If I am talking to genuine physical hardware, is it physically installed in this computer as opposed to someone else's computer?")</p>
<p>Hardware vendors are now architecting systems that can answer these questions accurately. In so doing, they endanger the benefits PC users have long enjoyed due to weaknesses in device authentication.</p>
<p>(Read on after the jump.)</p>
<p>
Ever since the ISA Plug-n-Play specification (and from the creation of the PCI bus), devices have had a means of identifying themselves. For example, a PCI video card will answer a request to identify itself by stating its device class (likely 0300, "VGA compatible controller"), manufacturer ID, and device model ID. There has not, however, been any sort of technical guarantee about the accuracy of such information. A manufacturer could create devices that claim to be other sorts of devices, and the only adverse consequence would be a greater likelihood of driver incompatibility.</p>
<p>"Device authentication" refers to techniques for giving software authentic information about what sort of hardware it is communicating with, and, in some cases, to giving hardware peripherals authentic information about the software that is communicating with them. The PCI ID system just discussed can be seen as a form of device authentication, but one without any sort of cryptographic basis. Stronger device authentication using cryptography has always been conceptually possible but has rarely been practiced on the PC (partly because of a traditional separation between hardware and software developers, partly because of implementation costs, and partly because of a lack of motivation prior to the emergence of the current DRM craze). One could argue that cryptographic smartcards are a species of device authentication because they can contain secret information that is difficult to copy and that can be used to prove that a device is present. However, very few PC users today use any sort of smartcard with their PCs.</p>
<p>The weakness of current device authentication techniques offers several significant benefits to PC users:</p>
<p>(1) Competition.</p>
<ul>In principle, the indistinguishability of devices is a good thing for competition because it prevents tying between driver software and hardware. For example, a competitor could make a new device that mimics the interface of an existing device all the way down to identifying itself the same way. (This might be important if some existing software expected to talk only to a single device model, for example.)
<p>In practice, the complexity of device drivers has usually made such tying possible even without formal device authentication mechanisms. (One could also say that the complexity of device drivers has served as a de facto device authentication mechanism.) Also, manufacturers who specifically want, for business reasons, to tie hardware and software together -- like Apple's iPod and iTunes -- have been creative in creating their own proprietary device authentication techniques.</p>
<p>Today, stronger protection for competition comes from the fact that many hardware manufacturers voluntarily implement the same interface standards, which makes rival devices relatively if not always completely substitutable for one another.</p></ul><p>(2) Emulation/virtualization.</p>
<ul>The indistinguishability of devices makes it easier to guarantee that existing software will continue to work under emulators and virtualizers like <a href="http://www.vmware.com/">VMWare</a>, <a href="http://bochs.sourceforge.net/">Bochs</a>, <a href="http://www.microsoft.com/mac/products/virtualpc/virtualpc.aspx">VirtualPC</a>, and others. These emulators allow users to run software within a virtual machine, providing security and compatibility benefits. Software that was originally written for a particular machine can typically run without modification on an emulated version of that machine.
<p>One key to making this work is emulating the machine's hardware -- that is, producing software constructs that look to software under emulation like real hardware. Emulator developers will code up software equivalents of hard drives, video cards, sound cards, keyboards, and more. Programs running within the emulator may not be able to tell the difference, and, indeed, in the ideal emulator could never tell the difference. That inability to distinguish physical from emulated hardware is vital to getting recalcitrant software to run under emulation.</p></ul><p>(3) Virtualized hardware for redirection and recording.</p>
<ul>Today, many software applications mimic hardware by redirecting application requests at some layer of an operating system. As just discussed, all emulators must do this in order to allow emulated software to communicate with the outside world. Mimicry is also useful for other purposes, including remote display and remote desktop applications. For instance, software that was written to display something on a locally attached monitor and to take input from a locally attached keyboard and mouse can be induced to interact instead with the same hardware on a machine hundreds or thousands of miles away.
<p>Applications that mimic sound cards use many of the same redirection techniques to allow audio streams to be recorded as they are played. Programs like <a href="http://www.highcriteria.com/">Total Recorder</a> allow the computer user to make a copy of whatever audio is sent to the sound card, which is helpful when programs produce audio output but lack a built-in recording function.</p></ul><p>(4) Privacy.</p>
<ul>If software can identify hardware well enough to read serial numbers or other unique IDs, it can use these to identify the user of the computer and to transmit this information over the Internet. Although this is a perennial privacy concern about the PC platform, it is heightened as software gets more and more reliable and detailed information about its hardware environment.</ul><p>Major hardware vendors are now taking giant steps toward several sorts of device authentication. These steps ultimately threaten each of the PC users' interests just described. Why would hardware vendors do this?</p>
<p>One major source of motivation for device authentication is Microsoft's Protected Media Path (PMP) project, a successor to the Secure Audio Path (SAP). PMP is motivated by entertainment companies' DRM ambitions and is being developed in consultation with them. Although parts of PMP are purely software-implemented and can work without hardware modification, Microsoft's complete PMP vision includes the ability to distinguish physical from virtual peripherals and to distinguish one peripheral make and model from another. Devices that lack authentication capabilities may not work with future software that uses PMP's device authentication features. Since PMP is expected to be used by authorized players for next-generation DVD discs, any manufacturer who doesn't play along risks forfeiting the Windows home theater market entirely.</p>
<p>Device authentication efforts are proceeding on several fronts and, for the most part, are not yet complete. The <a href="https://www.trustedcomputinggroup.org/home">Trusted Computing Group's</a> working group on peripherals, the PCI Forum, and Microsoft are all working on initiatives in this area, and standards documents for device authentication interfaces are likely to be published this year or next.</p>
<p>Device authentication is explicitly intended to break virtual soundcards and is projected to break emulators, or require the emulator developers to collaborate more closely with the developers of the hardware they emulate. Applications whose developers don't want them to work under emulation will obtain new weapons in their technology arsenal for detecting emulation.</p>
<p>What about the effect on privacy? The relationship between unique IDs in hardware, cryptographic protection of hardware interfaces, and privacy is complex. Privacy advocates observe that if there is something unique about your PC, software might be able to observe it and then reveal it over a network, providing the equivalent of a cookie that never expires, that can't be deleted, and that could potentially be shared across multiple sites or services. Making PCs truly indistinguishable from one another would mitigate this concern; so would preventing software from being able to access these sources of "uniqueness."</p>
<p>Technology developers often respond that there is no new privacy threat in adding a unique ID to any one hardware component, because PCs have contained many different unique IDs for years. For instance, a computer's Ethernet card and hard drive already contain serial numbers that are visible to software (and clever programmers can find numerous other things that could serve as unique IDs).</p>
<p>On the other hand, these existing approaches are not backed up with cryptography. It's difficult for software to tell whether the unique identifiers it observes in hardware are truly unique, or whether they might have been altered or tampered with. (For example, software running in an emulator might see the "hard drive" as having a serial number that's the same as the drive in every other copy of that emulator. Modern Ethernet cards have a means of altering their serial numbers from software, and other tricks abound for fooling software about its environment.) Once cryptographic device authentication enters the picture, however, software may acquire significantly stronger evidence about the hardware environment. It may become increasingly difficult to alter device serial numbers and to prevent software from learning -- and revealing -- which machine it's running on.</p>
<p>Ironically, the Trusted Computing Group spent a great deal of time addressing precisely this concern in connection with its Trusted Platform Module (TPM) chip. The TPM was carefully designed to prevent software from reading out its serial number and possibly using it as a cookie. Unfortunately, this privacy-protection effort may be for naught as other "authenticated" peripherals blithely give up their globally unique serial numbers to software -- in a cryptographically secured and trustworthy way.</p>
</div></div></div>Tue, 19 Jul 2005 13:52:42 +000059239 at https://www.eff.orgTrusted ComputingDerek Slater Microsoft Trusted Computing Updateshttps://www.eff.org/ar/deeplinks/2005/07/microsoft-trusted-computing-updates
<div class="field field--name-body field--type-text-with-summary field--label-hidden"><div class="field__items"><div class="field__item even"><p>Staff Technologist <a href="http://www.eff.org/about/staff/#seth_schoen">Seth Schoen</a>, EFF's resident expert on <a href="http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php">trusted computing</a>, recently attended this year's <a href="http://www.microsoft.com/whdc/winhec/default.mspx">Windows Hardware Engineering Conference</a> (WinHEC). Today we debut the first of a four-part series in which Schoen provides detailed updates on the status of Microsoft's security and lockware strategies for Windows. The outcome of these strategies will affect to what degree people using the platform and "trusted" PCs can maintain a <a href="http://www.linuxjournal.com/article/7055">desirable level of control</a> over their own computers.</p>
<p>*****</p>
<p>The most important message at the 2005 <a href="http://www.microsoft.com/whdc/winhec/default.mspx">WinHEC</a> about Microsoft's trusted computing effort, now known as <a href="http://www.microsoft.com/resources/ngscb/default.mspx">Next Generation Secure Computing Base</a> (NGSCB), is that it is late and will not be included in Windows Longhorn.</p>
<p>In fact, Microsoft is not implementing support in Longhorn for the <a href="http://www.eff.org/Infrastructure/trusted_computing/20031001_meditations.php">controversial</a> <a href="http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.php">remote attestation</a> features of trusted computing hardware. That means that publishers and service providers will not have a hardware-based means of forcing people to use particular programs for interoperability, nor of stopping people from reverse engineering or altering software on their own computers.</p>
<p>Microsoft is, however, continuing to develop digital rights management (DRM) technologies that could be strengthened directly by the use of trusted computing hardware in future operating system releases. Those DRM technologies are currently highly vulnerable to pure software attacks, and making those software attacks fail is one of several possible future trusted computing applications. One of Microsoft's DRM initiatives is known as "information rights management" (IRM), perhaps an attempt to avoid some of the stigma the term "DRM" carries with consumers. IRM is already supported in Microsoft Office, and, indeed, has been the subject of advertisements which portray it as a feature for preventing inadvertent disclosure of sensitive corporate information.</p>
<p>(Read on after the jump.)</p>
<p>
Although NGSCB isn't included in Longhorn, Microsoft and other software developers are coming up with useful applications of trusted computing for traditional, non-DRM-like security applications, such as protecting one's own files from being read by an unauthorized person.</p>
<p>Wave Systems, exhibiting at WinHEC, demonstrated software for Windows that uses a Trusted Computing Group (TCG) Trusted Platform Module (TPM) trusted computing chip to make traditional file encryption more robust. Microsoft plans to include conceptually related features in Windows Longhorn; if Longhorn is run on a system containing a TPM chip, it will be able to encrypt the entire hard drive using a TPM-protected key.</p>
<p>Microsoft's explanation of why you would want this centers on the idea of an epidemic of lost or stolen laptops containing sensitive information. It is already possible to encrypt laptop hard drives with hard drive encryption software, but this may be cumbersome; secure implementations could require users to choose long, hard-to-remember passphrases, and to enter those passphrases often. If the encryption key is stored on the hard drive itself, and protected with a short passphrase, it would be possible for someone who steals a laptop to run a passphrase-guessing program to try all possible passphrases in a relatively short time. Even if the laptop's operating system prohibits such a program from being run, the laptop's hard drive could be removed and installed in another machine. Thus, software hard drive encryption alone may be cumbersome or ineffective. (Microsoft has described other problems with pure software hard drive encryption, including what happens if a laptop hibernates and is woken up a long time later, what happens if a laptop has multiple authorized users with different passwords, and what happens if a computer contains sensitive information but needs to be able to boot or reboot without a human being present.)</p>
<p>Although there are software techniques that may address some of these problems, the use of a TPM's sealed storage feature is an appealingly simple approach. The TPM itself protects the access to the hard drive's decryption key; if the hard drive is removed from its original machine and placed into a new machine, the new machine will not be able to derive the decryption key. If the machine is made to boot a different operating system, the TPM will not be able to unseal the encrypted partitions on the hard drive. This is not a DRM-like application, however; authorized users retain the ability to make complete backups of all their data or to move it to another computer or software environment. (Because systems with encrypted hard drives have more failure modes than systems with unencrypted hard drives, it's especially important that users who choose to use such a feature do make regular backups!)</p>
<p>When a laptop protected with this technology is lost or stolen, its hard drive cannot usefully be decrypted if removed from the laptop; if the laptop is booted normally, however, its operating system will continue to enforce its security policy, denying access to anyone who does not present the appropriate passwords or credentials. This technique can also protect data on a machine in a colocation facility by denying access to anyone who steals or seizes the colocated machine. In a sense, TPM-based hard drive encryption means that obtaining physical access to a machine will no longer allow someone to obtain administrator-privileged access to the data stored on that machine. It does not, however, inherently impose any new restrictions on those with authorized access.</p>
<p>Still, Microsoft notes that a skilled person can attack the TPM from hardware. Thus, someone who steals a laptop might be able to use the PC equivalent of a video game console mod chip to bypass the TPM protections and recover data. The hardware necessary for this attack is inexpensive, but the skill and time required are fairly great. It may therefore be the case that TPM-based file or disk encryption will provide adequate protection for laptops against opportunistic or non-targeted attack. As even the Trusted Computing Group acknowledges, the TPM is not intended to protect against a skilled hardware attacker. If hardware attacks against the TPM become cheap and readily available, the kind of protection TPM-based trusted computing offers to a stolen laptop -- or a colocated machine with sensitive data -- may appear increasingly inadequate. In Microsoft's view, it is still likely strong enough to deter casual thieves from getting at sensitive information, because they are not likely to try to make sophisticated attempts to break a stolen system's security policy. On the other hand, law enforcement agents or corporate spies might well develop automated means of defeating this kind of security.</p>
<p>It's too early to tell, then, whether this trusted computing application will provide much incremental benefit over pure software encryption to particular kinds of users. Its biggest benefit may turn out to be in usability -- it will be bundled with Windows and relatively transparent, unlike much existing software encryption. It's thus more likely to be used, and used correctly and pervasively, than many other encryption technologies.</p>
<p>Microsoft's NGSCB project, although delayed, remains troubling because of its ability to strengthen DRM-like applications and facilitate software lock-in. There may also be a smooth upgrade path from the innocuous trusted computing implementation in Windows Longhorn to future implementations that help software impose restrictions on the user. Those who do see value in the TPM-based hard drive encryption should keep a close eye on what policies the TPM is enforcing and whose interest they serve. Microsoft, for its part, can keep NGSCB solidly on the user's side -- if it chooses -- by implementing a "owner override" that gives the computer owner ultimate control over which security policies the TPM will enforce.</p>
</div></div></div>Fri, 15 Jul 2005 13:08:09 +000059238 at https://www.eff.orgTrusted ComputingDerek Slater