Intel turning to hardware for rootkit detection

[crispin at novell.com (Crispin Cowan)]

Smashguard, if I recall correctly, offers approximately the protection
of existing compiler methods, but with the added fun of requiring
modified (non-existent) hardware.

The referenced hardware in the IEEE article and the intel.com pages
appears to be some descendant of Palladium; it is a hardware integrity
checker/attestation mechanism. A small, hardware-enforced core performs
a chain of crypto-checks prior to boot strapping the BIOS, and then the
OS, and makes itself available to applications. Thus an application can
(more or less) "prove" to a remote machine that the BIOS, kernel, and
application are in fact the "approved" versions that the remote machine
wants to see. The closest published work would be Bill Arbaugh's
dissertation and associated papers.

Real security benefit: remote machine can detect that your box has not
been rootkit'd.

Hoarding "benefit": remote machine can detect that you are running the
approved DRM-enforcing media player so that (for instance) it can
enforce that you only get to play that movie the specified number of
times and you don't get to copy it.

Malignant effect: Document master at an organization can make all
documents transient, so that whistle-blowers can no longer access the
documents they are trying to use to blow the whistle on such as, say,
Enron, WorldCom, or Abu Grab-ass.

Be very, very careful about tolerating strong-attestation hardware. The
implications are profound, for both good and evil.

Crispin

mudge wrote:
> There was a lady who went to Purdue, I believe her name was Carla
> Brodley. She is a professor at Tufts currently. One of her projects,
> I'm not sure whether it is ongoing or historic, was surrounding
> hardware based stack protection. There wasn't any protection against
> heap / pointer overflows and I don't know how it fares when stack
> trampoline activities (which can be valid, but are rare outside of
> older objective-c code).
>
> www.smashguard.org and https://engineering.purdue.edu/
> ResearchGroups/SmashGuard/smash.html have more data.
>
> I'm not sure if this is a similar solution to what Intel might be
> pursuing. I believe the original "smashguard" work was based entirely
> on Alpha chips.
>
> cheers,
>
> .mudge
>
>
> On Dec 13, 2005, at 15:19, Michael S Hines wrote:
>
> > Doesn't a hardware 'feature' such as this lock software into a
> > two-state model
> > (user/priv)?
> >
> > Who's to say that model is the best?  Will that be the model of the
> > future? 
> >
> > Wouldn't a two-state software model that works be more effective?  
> >
> > It's easier to change (patch) software than to rewire hardware
> > (figuratively speaking).
> >
> > Just wondering...
> >
> > Mike Hines
> > -----------------------------------
> > Michael S Hines
> > mshines at purdue.edu <mailto:mshines at purdue.edu> 
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org <mailto:SC-L at securecoding.org>
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>   

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com