Well I have just one thing to say, If this is used to protect contents (as
of audio or video) then it hardly makes any difference as finally all these
so called contents comes into analog forms and anyways i can capture them.
Even with something like HDCP, it can be achieved given the fact that
encrypting a session will always work on so called high performance
algorithms(read small key crypto non robust) if you check the HDCP standard
you will realize why I have a comment like this.
Now as far as providing protectioncrypto functions in the very
microprocessor is concerned well what if I have a memory emulators (those
boards with two ports one to connect to the motherboard and another to snoop
around and debug!) these type of boards are common in the embedded system
environment, what will stop someone who really want to break protection from
getting these boards and I mean the real content pirates here!
Again putting keys in microprocessor and crypto co-processos can delay the
breakin for sometime but not forever as remember you are distributing the
keys all the way, and if someone breaks the keys then your protection is
gone all together.
Anyways I think this thread is more on the driver signing issue less on DRM
as DRM by definition is weak and breakable. you are giving key, encrypted
text and crypto algorithm all to the attacker and then trying to defend the
encrypted text, how long can you defend it? All the security can be achieved
through obscurity which is never considered as secure anyway!
On 1/26/06, Jan Bottorff wrote:
>
> > One more thing! btw I dont understand one thing, Is this policy really
> > enforcable to the extent that no one can break it? I mean what it will
> > take to patch the kernel mode crypto code to let pass everything! As
> > long as memory is not shadowed or protected one can always do this
> > although it will be much harder! remember all PCs (to the best of
> > my knowledge!) start in the real mode so if one really wants to
> > bring down this signing mechanism, what I mean to say is that
> > all these mechanisims are NOT enforcable and not resistant
> > to patching ofcourse!
>
> If you read the AMD docs on their upcoming virtualization architecture
> there
> is also documentation on a facility to allow the processor to shift from
> an
> unverified mode, to a verified mode. This basically works by having an
> instruction that takes a signed code block. The signed code block’s
> signature is checked by the processor (actually I believe a security
> coprocessor) and control is transferred to it. You can bet there will not
> be
> many ways to get that core chunk of secure code signed. Once you are
> executing guaranteed secure code, it can verify the signature on other
> kernel components.
>
> I’d have to investigate further if this can protect memory from things
> like
> bus master DMA. It could prevent loading a bus master driver for hardware
> that didn’t do “secure” bus mastering. They could also have a way to lock
> the secure code in the cache, with no snooped changes. A little help from
> the motherboard chipset could further lock down a system, by making all
> DMA
> go through “map registers”. The OS could then absolutely control what
> memory
> could be accessed/changed by devices by only allowing a secure part of the
> OS to program those map registers (aren’t you glad you called the Windows
> DMA functions and didn’t just cheat on DMA programming).
>
> Another attack would be to run the OS on an emulated processor. Of course
> an
> emulated processor would not know the proper key to decrypt the initial
> secure code block, so it could never start the OS.
>
> Whoever controls the root crypto key will have ultimate control over what
> code runs or not. This absolutely could prevent unapproved OS’s from
> running, by having the BIOS code shift into secure mode. You might also
> allow both secure (Windows) and non-secure (Linux) OS’s to run, but only
> secure OS’s could run secure kernel components, and play DRM protected
> media. This could be extended to only allowing DRM secure systems access
> to
> the Internet. I’ve always believed a potential solution to Internet
> security
> is strong authentication. Spam only works because you can’t easily prove
> its
> source. I have zero problem always accessing the Internet as an
> authenticated me. Actually, since I use a static IP address, I already am
> traceable (ok not me absolutely, but my household). This seems like an
> opportunity for Microsoft to badly hurt Linux, and all they have to do is
> get on the DRM bandwagon with the media companies. This way it’s Disney
> who
> hurt Linux, not Microsoft. Disney has valid business reasons to protect
> their content, and as soon as Linux delivers DRM secure capability, they
> will be Disney’s friend too. I’d be all for a secure OS if it means I
> don’t
> have to renew my antivirus subscription ever again.
>
> If you were AMD or Intel, you might be able to slice open the processor
> chip
> and use your electron microscope (or whatever) to read the secure key,
> although your typical teenage hacker would not have facilities like this.
> There is quite a bit known about designing secure processors, and assume
> AMD
> and Intel could easily apply those techniques. Or there is a separate
> secure
> coprocessor on the motherboard.
>
> None of this is really a problem for developers. You could have the secure
> DRM components only allow access to test DRM protected content when in
> development mode. You could also have some DRM protected content with a
> production key that its owners didn’t care about protecting, so you could
> eliminate the argument of not testing REAL content. Patching the code in
> development mode is useless, as the patched binary will no longer run. The
> public security key is stored in the secure coprocessor, NOT in any files
> on
> your computer. It’s computationally impossible (until we get quantum
> computers) to figure out the private key based on having the signature, so
> properly implemented, it can’t be bypassed.
>
> Being a relative old timer in the computer industry (I’m 48 now), I’ve
> seen
> people get comfy and grumble at even the slightest change to the status
> quo,
> over and over. I WANT computers to evolve, things are REALLY broken right
> now. We know how to make better information systems, let’s do so. It’s
> REALLY cheap to have the tools needed to write software, next time you get
> an MRI, consider what it would be like if kernel debuggers cost what MRI
> machines cost (about $2 million bucks).
>
> - Jan
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
Ankit Raizada
Room No. 349
Boys Hostel
IIITA Campus
Deoghat Jhalwa
Allahabad - 211012
Email: xxxxx@iiita.ac.in
xxxxx@yahoo.com
xxxxx@gmail.com