Text 14974, 526 rader
Skriven 2006-12-23 05:15:00 av Gary Britt (1:261/1)
     Kommentar till en text av Mike
Ärende: Re: A Cost Analysis of Windows Vista Content Protection
===============================================================
 MSGID: 1:379/45 144d731b
 REPLY: 1:379/45 d1a574ef
 TZUTC: -0500
 CHARSET: PC-8
From: Gary Britt <GaryNOSPAMBritt@generalcogster.com>

So if one wants to move to Linux, how do you keep all this hardware encryption
and other bullshit from slowing down and destabilizing your Linux platform? 
Will you ever have a great video card with a pure DVI out on the back of it? 
Component video ?

Microsoft has been at this kind of crap for a long time.  I have an old sound
blaster live 5.1 sound card in a file server box.  It has digital audio out,
but its mostly useless because microsoft required that the driver turn off the
digital audio out under various circumstances.

Gary

mike wrote:
> http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt
>
>
> "...The Vista Content Protection specification could very well
> constitute the longest suicide note in history...."
>
>
> "...It's somewhat bizarre that I have to go to Communist China in order
> to find vendors who actually understand the consumer's needs...."
>
>
>
>
>
> ===
>            A Cost Analysis of Windows Vista Content Protection
>            ===================================================
>
>                 Peter Gutmann, pgut001@cs.auckland.ac.nz
>         http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt
>                       Last updated 22 December 2006
>
> Executive Summary
> -----------------
>
> Windows Vista includes an extensive reworking of core OS elements in
> order to provide content protection for so-called "premium content",
> typically HD data from Blu-Ray and HD-DVD sources.  Providing this
> protection incurs considerable costs in terms of system performance,
> system stability, technical support overhead, and hardware and software
> cost.  These issues affect not only users of Vista but the entire PC
> industry, since the effects of the protection measures extend to cover
> all hardware and software that will ever come into contact with Vista,
> even if it's not used directly with Vista (for example hardware in a
> Macintosh computer or on a Linux server).  This document analyses the
> cost involved in Vista's content protection, and the collateral damage
> that this incurs throughout the computer industry.
>
> Executive Executive Summary
> ---------------------------
>
> The Vista Content Protection specification could very well constitute
> the longest suicide note in history.
>
> Introduction
> ------------
>
> This document looks purely at the cost of the technical portions of
> Vista's content protection.  The political issues (under the heading of
> DRM) have been examined in exhaustive detail elsewhere and won't be
> commented on further, unless it's relevant to the cost analysis.
> However, one important point that must be kept in mind when reading this
> document is that in order to work, Vista's content protection must be
> able to violate the laws of physics, something that's unlikely to happen
> no matter how much the content industry wishes it were possible.  This
> conundrum is displayed over and over again in the Windows
> content-protection specs, with manufacturers being given no hard-
> and-fast guidelines but instead being instructed that they need to
> display as much dedication as possible to the party line.  The
> documentation is peppered with sentences like:
>
>    "It is recommended that a graphics manufacturer go beyond the strict
> letter   of the specification and provide additional content-protection
> features,   because this demonstrates their strong intent to protect
> premium content".
>
> This is an exceedingly strange way to write technical specifications,
> but is dictated by the fact that what the spec is trying to achieve is
> fundamentally impossible.  Readers should keep this requirement to
> display appropriate levels of dedication in mind when reading the
> following analysis [Note A].
>
> Disabling of Functionality
> --------------------------
>  Vista's content protection mechanism only allows protected content to
> be sent over interfaces that also have content-protection facilities
> built in. Currently the most common high-end audio output interface is
> S/PDIF (Sony/Philips Digital Interface Format).  Most newer audio cards,
> for example, feature TOSlink digital optical output for high-quality
> sound reproduction, and even the latest crop of motherboards with
> integrated audio provide at least coax (and often optical) digital
> output.  Since S/PDIF doesn't provide any content protection, Vista
> requires that it be disabled when playing protected content.  In other
> words if you've invested a pile of money into a high-end audio setup fed
> from a digital output, you won't be able to use it with protected
> content.  Similarly, component (YPbPr) video will be disabled by Vista's
> content protection, so the same applies to a high-end video setup fed
> from component video.
>
> Indirect Disabling of Functionality
> -----------------------------------
>
> As well as overt disabling of functionality, there's also covert
> disabling of functionality.  For example PC voice communications rely on
> automatic echo cancellation (AEC) in order to work.  AEC requires
> feeding back a sample of the audio mix into the echo cancellation
> subsystem, but with Vista's content protection this isn't permitted any
> more because this might allow access to premium content.  What is
> permitted is a highly-degraded form of feedback that might possibly
> still sort-of be enough for some sort of minimal echo cancellation
> purposes.
>
> The requirement to disable audio and video output plays havoc with
> standard system operations, because the security policy used is a
> so-called "system high" policy: The overall sensitivity level is that of
> the most sensitive data present in the system.  So the instant any audio
> derived from premium content appears on your system, signal degradation
> and disabling of outputs will occur.  What makes this particularly
> entertaining is the fact that the downgrading/disabling is dynamic, so
> if the premium-content signal is intermittent or varies (for example
> music that fades out), various outputs and output quality will fade in
> and out, or turn on and off, in sync.  Normally this behaviour would be
> a trigger for reinstalling device drivers or even a warranty return of
> the affected hardware, but in this case it's just a signal that
> everything is functioning as intended.
>
> Decreased Playback Quality
> --------------------------
>
> Alongside the all-or-nothing approach of disabling output, Vista
> requires that any interface that provides high-quality output degrade
> the signal quality that passes through it.  This is done through a
> "constrictor" that downgrades the signal to a much lower-quality one,
> then up-scales it again back to the original spec, but with a
> significant loss in quality.  So if you're using an expensive new LCD
> display fed from a high-quality DVI signal on your video card and
> there's protected content present, the picture you're going to see will
> be, as the spec puts it, "slightly fuzzy", a bit like a 10-year-old CRT
> monitor that you picked up for $2 at a yard sale.  In fact the spec
> specifically still allows for old VGA analog outputs, but even that's
> only because disallowing them would upset too many existing owners of
> analog monitors.  In the future even analog VGA output will probably
> have to be disabled.  The only thing that seems to be explicitly allowed
> is the extremely low-quality TV-out, provided that Macrovision is
> applied to it.
>
> The same deliberate degrading of playback quality applies to audio, with
> the audio being downgraded to sound (from the spec) "fuzzy with less
> detail".
>
> Amusingly, the Vista content protection docs say that it'll be left to
> graphics chip manufacturers to differentiate their product based on
> (deliberately degraded) video quality.  This seems a bit like breaking
> the legs of Olympic athletes and then rating them based on how fast they
> can hobble on crutches.
>
> Beyond the obvious playback-quality implications of deliberately
> degraded output, this measure can have serious repercussions in
> applications where high-quality reproduction of content is vital.  For
> example the field of medical imaging either bans outright or strongly
> frowns on any form of lossy compression because artifacts introduced by
> the compression process can cause mis-diagnoses and in extreme cases
> even become life-threatening.  Consider a medical IT worker who's using
> a medical imaging PC while listening to audio/video played back by the
> computer (the CDROM drives installed in workplace PCs inevitably spend
> most of their working lives playing music or MP3 CDs to drown out
> workplace noise).  If there's any premium content present in there, the
> image will be subtly altered by Vista's content protection, potentially
> creating exactly the life-threatening situation that the medical
> industry has worked so hard to avoid.  The scary thing is that there's
> no easy way around this - Vista will silently modify displayed content
> under certain (almost impossible-to-predict in advance) situations
> discernable only to Vista's built-in content-protection subsystem.
>
> Elimination of Open-source Hardware Support
> -------------------------------------------
>
> In order to prevent the creation of hardware emulators of protected
> output devices, Vista requires a Hardware Functionality Scan (HFS) that
> can be used to uniquely fingerprint a hardware device to ensure that
> it's (probably) genuine.  In order to do this, the driver on the host PC
> performs an operation in the hardware (for example rendering 3D content
> in a graphics card) that produces a result that's unique to that device
> type.
>
> In order for this to work, the spec requires that the operational
> details of the device be kept confidential.  Obviously anyone who knows
> enough about the workings of a device to operate it and to write a
> third-party driver for it (for example one for an open-source OS, or in
> general just any non-Windows OS) will also know enough to fake the HFS
> process.  The only way to protect the HFS process therefore is to not
> release any technical details on the device beyond a minimum required
> for web site reviews and comparison with other products.
>
> Elimination of Unified Drivers
> ------------------------------
>
> The HFS process has another cost involved with it.  Most hardware
> vendors have (thankfully) moved to unified driver models instead of the
> plethora of individual drivers that abounded some years ago.  Since HFS
> requires unique identification and handling of not just each device type
> (for example each graphics chip) but each variant of each device type
> (for example each stepping of each graphics chip) to handle the
> situation where a problem is found with one variation of a device, it's
> no longer possible to create one-size-fits-all drivers for an entire
> range of devices like the current Catalyst/Detonator/ForceWare drivers.
> Every little variation of every device type out there must now be
> individually accommodated in custom code in order for the HFS process to
> be fully effective.
>
> If a graphics chip is integrated directly into the motherboard and
> there's no easy access to the device bus then the need for bus
> encryption (see "Unnecessary CPU Resource Consumption" below) is
> removed.  Because the encryption requirement is so onerous, it's quite
> possible that this means of providing graphics capabilities will
> suddenly become more popular after the release of Vista.  However, this
> leads to a problem: It's no longer possible to tell if a graphics chip
> is situated on a plug-in card or attached to the motherboard, since as
> far as the system is concerned they're both just devices sitting on the
> AGP/PCIe bus.  The solution to this problem is to make the two
> deliberately incompatible, so that HFS can detect a chip on a plug-in
> card vs. one on the motherboard.  Again, this does nothing more than
> increase costs and driver complexity.
>
> Further problems occur with audio drivers.  To the system, HDMI audio
> looks like S/PDIF, a deliberate design decision to make handling of
> drivers easier. In order to provide the ability to disable output, it's
> necessary to make HDMI codecs deliberately incompatible with S/PDIF
> codecs, despite the fact that they were specifically designed to appear
> identical in order to ease driver support and reduce development costs.
>
> Denial-of-Service via Driver Revocation
> ---------------------------------------
>
> Once a weakness is found in a particular driver or device, that driver
> will have its signature revoked by Microsoft, which means that it will
> cease to function (details on this are a bit vague here, presumably some
> minimum functionality like generic 640x480 VGA support will still be
> available in order for the system to boot).  This means that a report of
> a compromise of a particular driver or device will cause all support for
> that device worldwide to be turned off until a fix can be found.  Again,
> details are sketchy, but if it's a device problem then presumably the
> device turns into a paperweight once it's revoked.  If it's an older
> device for which the vendor isn't interested in rewriting their drivers
> (and in the fast-moving hardware market most devices enter "legacy"
> status within a year of two of their replacement models becoming
> available), all devices of that type worldwide become permanently
> unusable.
>
> The threat of driver revocation is the ultimate nuclear option, the
> crack of the commissars' pistols reminding the faithful of their duty
> [Note B].  The exact details of the hammer that vendors will be hit with
> is buried in confidential licensing agreements, but I've heard mention
> of multimillion dollar fines and embargoes on further shipment of
> devices alongside the driver revocation mentioned above.
>
> Decreased System Reliability
> ----------------------------
>
> Vista's content protection requires that devices (hardware and software
> drivers) set so-called "tilt bits" if they detect anything unusual.  For
> example if there are unusual voltage fluctuations, maybe some jitter on
> bus signals, a slightly funny return code from a function call, a device
> register that doesn't contain quite the value that was expected, or
> anything similar, a tilt bit gets set.  Such occurrences aren't too
> uncommon in a typical computer (for example starting up or plugging in a
> bus-powered device may cause a small glitch in power supply voltages, or
> drivers may not quite manage device state as precisely as they think).
> Previously this was no problem - the system was designed with a bit of
> resilience, and things will function as normal.  In other words small
> variances in performance are a normal part of system functioning.
> Furthermore, the degree of variance can differ widely across systems,
> with some handling large changes in system parameters and others only
> small ones.  One very obvious way to observe this is what happens when a
> bunch of PCs get hit by a momentary power outage.  Effects will vary
> from powering down, to various types of crash, to nothing at all, all
> triggered by exactly the same external event.
>
> With the introduction of tilt bits, all of this designed-in resilience
> is gone.  Every little (normally unnoticeable) glitch is suddenly
> surfaced because it could be a sign of a hack attack.  The effect that
> this will have on system reliability should require no further
> explanation.
>
> Content-protection "features" like tilt bits also have worrying
> denial-of- service (DoS) implications.  It's probably a good thing that
> modern malware is created by programmers with the commercial interests
> of the phishing and spam industries in mind rather than just creating as
> much havoc as possible.  With the number of easily-accessible grenade
> pins that Vista's content protection provides, any piece of malware that
> decides to pull a few of them will cause considerable damage.  The
> homeland security implications of this seem quite serious, since a tiny,
> easily-hidden piece of malware would be enough to render a machine
> unusable, while the very nature of Vista's content protection would make
> it almost impossible to determine why the denial-of-service is
> occurring.  Furthermore, the malware authors, who are taking advantage
> of "content-protection" features, would be protected by the DMCA against
> any attempts to reverse-engineer or disable the content-protection
> "features" that they're abusing.
>
> Even without deliberate abuse by malware, the homeland security
> implications of an external agent being empowered to turn off your IT
> infrastructure in response to a content leak discovered in some chipset
> that you coincidentally happen to be using is a serious concern for
> potential Vista users.  Non-US governments are already nervous enough
> about using a US-supplied operating system without having this remote
> DoS capability built into the operating system.  And like the
> medical-image-degradation issue, you won't find out about this until
> it's too late, turning Vista PCs into ticking time bombs if the
> revocation functionality is ever employed.
>
> Increased Hardware Costs
> ------------------------
>  Vista includes various requirements for "robustness" in which the
> content industry, through "hardware robustness rules", dictates design
> requirements to hardware manufacturers.  For example, only certain
> layouts of a board are allowed in order to make it harder for outsiders
> to access parts of the board. Possibly for the first time ever, computer
> design is being dictated not by electronic design rules, physical layout
> requirements, and thermal issues, but by the wishes of the content
> industry. Apart from the massive headache that this poses to device
> manufacturers, it also imposes additional increased costs beyond the
> ones incurred simply by having to lay out board designs in a suboptimal
> manner.  Video card manufacturers typically produce a one-size- fits-all
> design (often a minimally-altered copy of the chipset vendor's reference
> design), and then populate different classes and price levels of cards
> in different ways.  For example a low-end card will have low-cost,
> minimal or absent TV-out encoders, DVI circuitry, RAMDACs, and various
> other add-ons used to differentiate budget from premium video cards. You
> can see this on the cheaper cards by observing the unpopulated bond pads
> on circuit boards, and gamers and the like will be familiar with
> cut-a-trace/resolder-a- resistor sidegrades of video cards. Vista's
> content-protection requirements eliminate this one-size-fits-all design,
> banning the use of separate TV-out encoders, DVI circuitry, RAMDACs, and
> other discretionary add-ons.  Everything has to be custom-designed and
> laid out so that there are no unnecessary accessible signal links on the
> board.  This means that a low-cost card isn't just a high-cost card with
> components omitted, and conversely a high-cost card isn't just a
> low-cost card with additional discretionary components added, each one
> has to be a completely custom design created to ensure that no signal on
> the board is accessible.
>
> This extends beyond simple board design all the way down to chip design.
> Instead of adding an external DVI chip, it now has to be integrated into
> the graphics chip, along with any other functionality normally supplied
> by an external chip.  So instead of varying video card cost based on
> optional components, the chipset vendor now has to integrate everything
> into a one- size-fits-all premium-featured graphics chip, even if all
> the user wants is a budget card for their kids' PC.
>
> Increased Cost due to Requirement to License Unnecessary Third-party IP
> -----------------------------------------------------------------------
>  Protecting all of this precious premium content requires a lot of
> additional technology.  Unfortunately much of this is owned by third
> parties and requires additional licensing.  For example HDCP for HDMI is
> owned by Intel, so in order to send a signal over HDMI you have to pay
> royalties to Intel, even though you could do exactly the same thing for
> free over DVI.  Similarly, since even AES-128 on a modern CPU isn't fast
> enough to encrypt high-bandwidth content, companies are required to
> license the Intel-owned Cascaded Cipher, an AES-128-based transform
> that's designed to offer a generally similar level of security but with
> less processing overhead.
>
> The need to obtain unnecessary technology licenses extends beyond basic
> hardware IP.  In order to demonstrate their commitment to the cause,
> Microsoft have recommended as part of their "robustness rules" that
> vendors license third-party code obfuscation tools to provide virus-like
> stealth capabilities for their device drivers in order to make it
> difficult to interfere with their operations or reverse-engineer them.
> Vendors like Cloakware and Arxan have actually added "robustness
> solutions" web pages to their sites in anticipation of this lucrative
> market.  This must be a nightmare for device vendors, for whom it's
> already enough of a task getting fully functional drivers deployed
> without having to deal with adding stealth-virus-like technology on top
> of the basic driver functionality.
>
> Unnecessary CPU Resource Consumption
> ------------------------------------
>
> In order to prevent tampering with in-system communications, all
> communication flows have to be encrypted and/or authenticated.  For
> example content to video cards has to be encrypted with AES-128.  This
> requirement for cryptography extends beyond basic content encryption to
> encompass not just data flowing over various buses but also command and
> control data flowing between software components.  For example
> communications between user-mode and kernel-mode components are
> authenticated with OMAC message authentication-code tags, at
> considerable cost to both ends of the connection.
>
> In order to prevent active attacks, device drivers are required to poll
> the underlying hardware ever 30ms to ensure that everything appears
> kosher.  This means that even with nothing else happening in the system,
> a mass of assorted drivers has to wake up thirty times a second just to
> ensure that... nothing continues to happen.  In addition to this
> polling, further device-specific polling is also done, for example Vista
> polls video devices on each video frame displayed in order to check that
> all of the grenade pins (tilt bits) are still as they should be.
>
> On-board graphics create an additional problem in that blocks of
> precious content will end up stored in system memory, from where they
> could be paged to disk.  In order to avoid this, Vista tags such pages
> with a special protection bit indicating that they need to be encrypted
> before being paged out and decrypted again after being paged in.  Vista
> doesn't provide any other pagefile encryption, and will quite happily
> page banking PINs, credit card details, private, personal data, and
> other sensitive information, in plaintext.  The content-protection
> requirements make it fairly clear that in Microsoft's eyes a frame of
> premium content is worth more than (say) a user's medical records or
> their banking PIN.
>
> In addition to the CPU costs, the desire to render data inaccessible at
> any level means that video decompression can't be done in the CPU any
> more, since there isn't sufficient CPU power available to both
> decompress the video and encrypt the resulting uncompressed data stream
> to the video card.  As a result, much of the decompression has to be
> integrated into the graphics chip. At a minimum this includes IDCT, MPEG
> motion compensation, and the Windows Media VC-1 codec.  As a corollary
> to the "Increased Hardware Costs" problem above, this means that you
> can't ship a low-end graphics chip without video codec support any more.
>
> The inability to perform decoding in software also means that any
> premium- content compression scheme not supported by the graphics
> hardware can't be implemented.  If things like the Ogg video codec ever
> eventuate and get used for premium content, they had better be done
> using something like Windows Media VC-1 or they'll be a non-starter
> under Vista or Vista-approved hardware. This is particularly troubling
> for the high-quality digital cinema (D-Cinema) specification, which uses
> Motion JPEG2000 (MJ2K) because standard MPEG and equivalents don't
> provide sufficient image quality.  Since JPEG2000 uses wavelet-based
> compression rather than MPEG's DCT-based compression, and wavelet-based
> compression isn't on the hardware codec list, it's not possible to play
> back D-Cinema premium content.  Because *all* D-Cinema content will
> (presumably) be premium content, the result is no playback at all until
> the hardware support appears in PCs at some indeterminate point in the
> future. Compare this to the situation with MPEG video, where early
> software codecs like the XingMPEG en/decoder practically created the
> market for PC video. Today, thanks to Vista's content protection, the
> opening up of new markets in this manner would be impossible.
>
> The high-end graphics and audio market are dominated entirely by gamers,
> who will do anything to gain the tiniest bit of extra performance, like
> buying Bigfoot Networks' $250 "Killer NIC" ethernet card in the hope
> that it'll help reduce their network latency by a few milliseconds.
> These are people buying $500-$1000 graphics and sound cards for which
> one single sale brings the device vendors more than the few cents they
> get from the video/audio portion of an entire roomful of
> integrated-graphics-and-sound PCs.  I wonder how this market segment
> will react to knowing that their top-of-the-line hardware is being
> hamstrung by all of the content-protection "features" that Vista hogties
> it with?
>
> Unnecessary Device Resource Consumption
> ---------------------------------------
>
> As part of the bus-protection scheme, devices are required to implement
> AES-128 encryption in order to receive content from Vista.  This has to
> be done via a hardware decryption engine on the graphics chip, which
> would typically be implemented by throwing away a rendering pipeline or
> two to make room for the AES engine.
>
> Establishing the AES key with the device hardware requires further
> cryptographic overhead, in this case a 2048-bit Diffie-Hellman key
> exchange. In programmable devices this can be done (with considerable
> effort) in the device (for example in programmable shader hardware), or
> more simply by throwing out a few more rendering pipelines and
> implementing a public-key- cryptography engine in the freed-up space.
>
> Needless to say, the need to develop, test, and integrate encryption
> engines into audio/video devices will only add to their cost, as covered
> in "Increased Hardware Costs" above, and the fact that their losing
> precious performance in order to accommodate Vista's content protection
> will make gamers less than happy.
>
> Final Thoughts
> --------------
>  "No amount of coordination will be successful unless it's designed with
> the needs of the customer in mind.  Microsoft believes that a good user
> experience is a requirement for adoption" -- Microsoft.
>
> At the end of all this, the question remains: Why is Microsoft going to
> this much trouble?  Ask most people what they picture when you use the
> term "premium media player" and they'll respond with "A PVR" or "A DVD
> player" and not "A Windows PC".  So why go to this much effort to try
> and turn the PC into something that it's not?
>
> In July 2006, Cory Doctorow published an analysis of the
> anti-competitive nature of Apple's iTunes copy-restriction system
> ("Apple's Copy Protection Isn't Just Bad For Consumers, It's Bad For
> Business", Cory Doctorow, Information Week, 31 July 2006).  The only
> reason I can imagine why Microsoft would put its programmers, device
> vendors, third-party developers, and ultimately its customers, through
> this much pain is because once this copy protection is entrenched,
> Microsoft will completely own the distribution channel.  In the same way
> that Apple has managed to acquire a monopolistic lock-in on their music
> distribution channel (an example being the Motorola ROKR fiasco, which
> was so crippled by Apple-imposed restrictions that it was dead the
> moment it appeared), so Microsoft will totally control the premium-
> content distribution channel.  Not only will they be able to lock out
> any competitors, but because they will then represent the only available
> distribution channel they'll be able to dictate terms back to the
> content providers whose needs they are nominally serving in the same way
> that Apple has already dictated terms back to the music industry: Play
> by Apple's rules, or we won't carry your content. The result will be a
> technologically enforced monopoly that makes their current de-facto
> Windows monopoly seem like a velvet glove in comparison.
>
> Overall, Vista's content-protection functionality seems like an
> astonishingly short-sighted piece of engineering, concentrating entirely
> on content protection with no consideration given to the enormous
> repercussions of the measures employed.  It's something like the PC
> equivalent of the (hastily dropped) proposal mooted in Europe to put
> RFID tags into high-value banknotes as an anti-counterfeiting measure,
> completely ignoring the fact that the major users of this technology
> would end up being criminals who would use it to remotely identify the
> mo
--- QScan/WC v1.20a / 02-****
 * Origin:  (1:261/1)