Vista Security The 'Longest Suicide Note in History'?

rar42 writes "The Inquirer is reporting on an analysis of Vista by Peter Gutmann — a medical imaging specialist. This isn't the usual anti-Microsoft story — just a professional looking at what is going to happen to his computer if it is upgraded to Microsoft Vista. From the article: '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,' says Gutmann."

Comments

Dupe from Friday

[ahecht]

Same story at http://it.slashdot.org/article.pl?sid=06/12/22/172 7245

Primary Sources, FTW!

[Grym]

Here's a link to the actual paper referenced in the article.

I would post the entire paper, but it's too large. Here are some notable excerpts:

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.

Vista's content protection mechanism only allows protected content to be sent over interfaces that also have content-protection facilities built in... 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.

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... 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.

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... 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

Medical Imaging Specialist????

[perry]

Peter is a security guy. He's written widely used crypto software. He is not a medical imaging specialist. Where did /. get the idea that he's a medical imaging specialist???

Re:Well then don't use it

[ceoyoyo]

Unfortunately there's very little choice. The systems that run medical scanners tend to run some form of UNIX, and you can buy a workstation for a couple hundred thousand that will do the same thing, or you can use the hospital's PACS web front end... which in most cases works pretty much exclusively with IE.

I'm new here but...

[monoqlith]

Could someone please like, read....something before they post a summary? I found no indication that Gutmann is a medical imaging specialist from his web page or report. He's a computer scientist who specializes in compression and encryption, which actually makes him a little bit qualified to perform a professional review of the new operating system.

The only thing remotely medicine related here is a quote from 'Brad Steffler MD.', a surgeon who claims that Microsoft's restrictive DRM methodologies make it more difficult for him to do his job.

Brief Outline of Medical Imaging Information Flow

[Ears]

This is part of the subtext both of the original article, and of this most recent post, so I thought I'd share what I know about it. FWIW, I'm a radiologist--that is, an MD who interprets the results of imaging studies--and an informatics geek.

Images are created on whatever imaging device--CT scanner, MR scanner, ultrasound machine, digital X-ray machine--and manipulated by the device's controlling system to do simple annotations, reformatting, etc. This is typically a Unix-based system running custom software designed and maintained by the device's vendor. The images are not usually interpreted on these systems.

From there, the images are sent to the PACS (Picutre Archiving and Communication System), which is just a gigantic central image database. These also tend to be Unix-based systems.

There tend to be two front-ends for looking at images in the PACS database. The first is the radiologist's interface, which is a high-end video workstation dedicated to showing medical images with the greatest possible fidelity. Most systems I've seen are Windows-based (Windows 2000, in our case) and run software which was built by the the imaging system vendors in the late 1990's. Much is made of the "lossless" nature of the images which are displayed; for example, when you log into such a machine, you're warned about how "This is a medical device" and that you shouldn't mess with it. Much is also made of "diagnostic-quality monitors" and high-end video cards to drive the monitors. This is an artifact from the early days of digital imaging interpretation in radiology, when there was a great deal of concern about whether the quality of the digital images would be adequate for us to figure out what was going on in Grandma's chest X-ray if we weren't looking at a piece of acetate. Most of these concerns have died away, as the differences in resolution and dynamic range turned out to be relatively minor and the added conveniences of being able to manipulate the images digitally turned out to be huge. For example, the new LCDs I seen being put on PACS workstations are off-the-shelf Dell 22-inchers, as far as I can tell.

Finally, there are "non-diagnostic" interfaces to the PACS images, which do tend to be web-based. These are so non-radiologist doctors can look at the images, too. Some are IE-based, and use an ActiveX control to display the images, and some use a Java applet. These are displayed with lossy compression (since someone might want to look at them from off-site via a VPN), and officially are not allowed to be used for interpretation. And in fact, I wouldn't want to; it's a lot harder to see subtle things on them than on a full-blown PACS workstation. Part of that is just the interface (it's hard to use those stupid ActiveX/applet things) and part of it is crummy/mis-configured monitors, but I suppose compression artifacts could also play a role.

So, to review: you go see your doctor, Dr. Smith, in her office, and she orders a chest X-ray for you because you're coughing and have a fever. You come to the hospital, and the nice technologist takes frontal and lateral view of your chest on the digital X-ray machine. He then goes back to the X-ray control room, and sees that the images are pretty good, and so he sticks your name on them, and a marker of the date/time and his name, and so on, and then sends them to the hospital's PACS system. I (the radiologist) am working at my PACS workstation, going through the long list of all of the CT scans, MR scans, and X-rays taken in the hospital. I get to your chest X-ray and look at it; I don't seen any sign of pneumonia, so I write a report (the subject of a whole different set of informatics) that basically says "Clear lungs" and that gets entered into your electronic medical record. Then, Dr. Smith back in her office can see your X-ray via her Web-based interface. If she wonders about something she sees, she can call me up and say, "What's that stuff at the left ape