A squadron of heavily armed IBM spin bombers left their hilltop base at Almaden, Ca at the end of last week. Their destination - Vulture Central. Their mission - to disarm public outrage at the proposed inclusion of CPRM copy control mechanisms into hard disks. The bombers were loaded with a good-natured arsenal of flattery, non sequiters, and laser-guided hand waves.

Normally we'd send such missives straight to the bit bucket, but on this occasion, they're worth airing. Not just because this is spin of a subtle quality that we rarely hear - although it is - but it gives the best clue yet of how the industry will attempt to massage public concern on the subject. And to be forewarned is to be forearmed, we reckon.

Before we get stuck in, however, acquaint yourselves with the CPRM proposals at first hand. The T.13 committee makes documents freely downloadable, and the two you really want to read are the latest Content Protection of Recordable Media proposal and a 24-slide Presentation by the same author, Jeff Lotspiech of IBM's Almaden Lab, which gives a bird's eye view of the subject. Another useful document is an article in IBM Research's own house magazine Doh! [shouldn't that be Think - ed.] where CPRM's twin brother CPPM is discussed. This explains the mechanics of CPRM in layman's terms, but of how sophisticated the system is, and the challenge it presents to would-be hackers.

But as you peruse the T.13 documents, ask yourself "Why is this even here?". ... And ask yourself the same question at regular intervals in the next few paragraphs.

Go away folks, there's nothing to see
"What they[4C] 're asking for in the ATA standard is not to incorporate content protection but to reserve some space in the spec for calls or functions that content protection that others could call upon," insists Mike Ross, spokesman for IBM's Alamaden Labs. But Lotspiech's cryptographic structure for CPRM is well defined already. The system interface is also defined in the CPRM technical proposal: in excruciating detail, as you can read in the references above.

"CPRM is NOT tied to a fixed location on the disk," says Ross. "The Media Key Block can be placed anywhere that is convenient for the manufacturer."

Wow, we thought: this guys's good. This guy's really good.

But it's nonsense of course, and what can most charitably described as a straw man. Recall that there are two areas that CPRM can be said to reside - and here, use page 10 of the presentation above. The Media Key Block (which is most of that megabyte) is in a read-only area, and the Media Unique Key (which uniquely identifies the disk) is in a "hidden area". Both are what is called "vendor space" - the part that handles out of bounds sector swapping, and that's separate from the file system itself. It's a puzzling assertion, as we don't remember claiming that CPRM is tied to a physical location on the disk ourselves, but we did point out - and the specification points out - that CPRM physically locks signed media into a given location, driving a bus through the concept of file system abstraction.

Hard disk experts tell us that at a device level, when issuing a write command you don't really know where you putting it, so there's a couple of levels of abstraction going on here. But CPRM in ATA breaks one of them, and that in itself is only the beginning of where the proposal is so fundamentally redraws the computer landscape.

As Ross confirms: "All of the content files can be moved, copied, even renamed -- in their encrypted form. CPRM only insures that the protected files are played or viewed only by compliant software or devices" [our emphasis, natch].

As for the short-term damage to commodity RAID, file optimisation, backup, and potentially imaging software too, Ross says "These are good points, these issues will have to be addressed in the marketplace and you're absolutely right - but these have not even been discussed yet."

Porky packets
IBM insists that the proposals are intended to secure content on removable media, and that hard disks aren't really the target: although in Ross' words "Would a hard drive benefit from the calls requested here? Absolutely - so you could take that to the next step"

But let's look at the context for a second. There's ATAPI - the spec for removable media, and then there's ATA - the spec for hard disks. They're closely related, and share semantical similarities, but also differ significantly. ATAPI is a packet format. What's being proposed isn't ATAPI - it's ATA, and contains information that ATA devices need, but that ATAPI devices don't. In other words, the specification can be rolled into fixed, ATA devices right off the bat.

So how mandatory are these specifications? Dave Anderson of the Object Based Storage Device group - he's also Seagate's storage architect, but was speaking to us with his OBSD hat on - points out that not all of the SCSI command set has been implemented. Even where the commands have obvious benefits. It's a good point, but it's also worth remembering that the SCSI design philosophy (do more) differs from ATA mores (keep it simple) with the consequence that the ATA spec is much more closely adhered to by manufacturers. It's a far simpler spec, and being a mass market, doesn't tolerate wibbles. CPRM's backers point out that it's an optional mechanism, and needs to be turned on explicitly: for example a "compliant" CPRM drive may yet be programmed to reject calls by compliant applications to write secure media to disk.

The T.13 committee next meets in Irvine in February. It's already seen three drafts of CPRM, which may give opponents of the scheme hope that it can be delayed further. Equally, we suspect, CPRM's backers may hope that the pre-Xmas furore will be forgotten as we nurse new century hangovers in just over a week. But CPRM in ATA poses short-term problems for several classes of current software and IT practices, long-term threats to accepted consumer free use practice and to basic computer science principles such as file system abstraction, and could particularly divisive for free software in particular - as Richard Stallman has pointed out. In short, it has the potential to make the Clipper Chip saga look like a pre-show warm-up, and we wouldn't bet on this story going away anytime soon. As the Grinch discovered: "Oh, the noise! That's one thing he hated! The NOISE! ®

Related stories

Stealth plan puts copy protection into every hard drive
Linux lead slams 'pay per read' disk drive plan
Copy protection hard drive plan nixes free software - RMS