maximize best case, worst case, or average case? (TCPA)

[Ryan Lackey]

Quoting lynn.wheeler at firstdata.com <lynn.wheeler at firstdata.com>:
> 
> "security modules" are also inside the swipe & pin-entry boxes that you see
> at check-out counters.

Yep -- anything which handles PINs, specifically, and some non-ATM smartcard
payment systems.
> 
> effectively both smartcards and dongles are forms of hardware tokens ....
> the issue would be whether a smartcard form factor might be utilized in a
> copy protection scheme similar to TCPA paradigm .... a single hardware chip
> that you register for all you applications .... or in the dongle paradigm
> .... you get a different smartcard for each application (with the downside
> of the floppy copy protection scenario where a user with a half dozen
> active copy protected applications all wanted "their" smartcard crammed
> into the same smartcard reader simultaneously).

>From a DRM perspective, any system which doesn't put the entire digital stream
and all convenient analog streams inside the trusted, tamperproof boundary
is probably highly imperfect, perhaps to the point where it's really just
a speedbump, no more effective than popping up a dialog box saying "please
don't pirate this software" with a click though EULA.

A concrete example is the DVD.  RPC 1 allowed raw access to the encrypted
data; the encryption could be broken through several techniques (disassembly
of software players to recover keys, or as happened, vulnerabilities in the
algorithm).

Then they came out with RPC 2.  Implementation is highly imperfect (for a 
variety of reasons), but in theory, this renders the whole DeCSS issue 
relatively dead -- the drive itself will refuse to output a bitstream of any
kind if the region coding is wrong.

RPC 2 can, in theory, prevent the playback of media on drives without the
right region code.  It doesn't, however, prevent grabbing the bitstream off
a licensed dvd in a correct-region player, turning that into a DivX, and 
distributing it widely.

Any system which uses a tamper-resistant envelope which doesn't encompass the
entire digital playback stream will end up with this same vulnerability.  It
deters "casual" defeat of the DRM system -- you need to specifically seek
out a pirate copy of the movie in the first place, rather than buying a grey
market import.

In addition, there is the "analog hole"; even if the digital bitstream is
protected fully, any high-quality analog output can be re-digitized and
turned into a fairly acceptable version.   People even go so far as to 
do telecine of a kind, aiming a video camera at the screen in a theater.

If it is possible for the underground to distribute a worthwhile copy some
hours or days after initial release, any system with digital or analog hole
will suffer.  This is why, for instance, movies are widely divxed or 
illegally VCD'd; movies are still worth seeing a few hours after the first
copies hit the distributors and reviewers (still a few weeks or months ahead
of public release).  However, a live event on pay per view, like a boxing
match or world cup, is much less widely pirated in divx form; even if you can
get a good digital or analog copy of it after the event, who wants to watch it
then?

I think this means, given a constant level of piracy and limitations on DRM,
there is a market incentive to do live and simultaneous global media events,
vs. things which are watchable later for roughly the same value.  Also, 
streaming p2p systems or pirate networks are far easier to detect and shut down
than systems with high inbuilt latency.

If content providers shifted their business model to emphasize these 
"ephemeral" forms of content, rather than things with lasting value,
they would be able to avoid problems with piracy simply by going after
very large, centralized real-time distributors.  This is ultimately 
far more cost effective and politically viable than trying to lock every
device in the world down.  I think there is already a marketing focus on
making "events" out of the release of even durable forms of content --
book launches, movie premieres, etc. -- in the future, perhaps, this
initial event will be the source of the majority of revenue, with residuals
after that event wrapped up in the form of service fees for access to 
an unlimited library.  After all, isn't going to an event like Woodstock
worth far more to the average user than a complete audio/video record
of the event after the fact?

> 
> many of the current chipcards .... i believe are used in the magnetic
> stripe "swipe" mode for authenticating specific transactions ....  most of
> the rest are used for password substitute at login type events. Many of the
> chipcards following the straight payment card model result in end-user
> having large number of different institutional tokens (similar to the
> floppy copy protect paradigm).  Following the institutional-specific and/or
> application-specific token paradigm starts to become difficult to manage as
> the number of tokens increase and the probability that multiple are
> required simultaneously increases.
> 
> That eventually leads into some sort of person-centric or device-centric
> paradigm .... not so much an issue of the form factor  (floppy, chipcard,
> dongle, etc) .... but an issue of whether there are potentially large
> numbers of institutional/application specific objects or small numbers of
> person/device specific objects.
> 
> So a simple issue is the trade-off between the institutional/application
> specific objects .... which seem to have some amount of acceptance (payment
> cards, chip cards, various "dongle" forms, etc) but in many instances can
> scale poorly ... especially if  multiple different such objects have to be
> available concurrently .... vis-a-vis switching to a person/device specific
> object paradigm (chipcard, dongles, etc, potentially exactly same
> formfactor but different paradigm)
> 
> 
> 
> ryan at havenco.com on 6/30/2002 12:39 pm wrote:
> 
> 
> I think dongles (and non-copyable floppies) have been around since the
> early
> 80s at least...maybe the 70s.  Tamper-resistant CPU modules have been
> around
> since the ATM network, I believe, in the form of PIN processors stored
> inside safes)
> 
> The fundamental difference between a "dongle" and a full "trusted module"
> containing the critical application code is that with a dongle, you can
> just patch the application to skip over the checks (although they can be
> repeated, and relatively arcane).
> 
> If the whole application, or at least the non-cloneable parts of the
> application, exist in a sealed module, the rest of the application can't
> be patched to just skip over this code.
> 
> Another option for this is a client server or oracle model where the really
> 
> sensitive pieces (say, a magic algorithm for finding oil from GIS data,
> or a good natural language processor) are stored on vendor-controlled
> hardware centrally located, with only the UI executing on the end user's
> machine.
> 
> What I'd really like is a design which accomplishes the "good" parts of
> TCPA,
> ensuring that when code claims to be executing in a certain form, it really
> is,
> and providing a way to guarantee this remotely -- without making it easy
> to implement restrictions on content copying.  It would be nice to have the
> good parts of TCPA, and given the resistance to DRM, if security and TCPA
> have their fates bound, they'll probably both die an extended and painful
> death.
> 
> I suppose the real difference between a crypto-specific module and a
> general
> purpose module is how much of the UI is within the trusted platform
> envelope.
> If the module is only used for handling cryptographic keys, as an addition
> to
> an insecure general purpose CPU, with no user I/O, it seems unlikely to be
> useful for DRM.  If the entire machine is inside the envelope, it seems
> obviously useful for DRM, and DRM would likely be the dominant application.
> If only a limited user IO is included in the envelope, sufficient for
> user authentication and keying, and to allow the user to load
> initially-trusted code onto the general purpose CPU, but where the user
> can fully use whatever general purpose code on the general purpose CPU,
> even uncertified code, with the certified module, it's not really useful
> for DRM, but still useful for the non-DRM security applications which are
> the alleged purpose behind TCPA.
> 
> (given that text piracy doesn't seem to be a serious commercial concern,
> simply keeping video and audio playback and network communications outside
> the TCPA envelope entirely is good enough, in practice...this way, both
> authentication and keying can be done in text mode, and document
> distribution control, privacy of records, etc. can be accomplished,
> provided
> there is ALSO the ability to do arbitrary text processing and computing
> outside the trusted envelope, .)
> 
> If it's the user's own data being protected, you don't need to worry about
> the user intentionally circumventing the protections.  Any design which
> removes control from the 'superuser' of the machine is fundamentally about
> protecting someone other than the user.
> 
> This, I think, is the difference between TCPA and smartcards.  Notice
> which one has in its short lifetime attracted far more enmity :)
> 
> 
> Quoting lynn.wheeler at firstdata.com <lynn.wheeler at firstdata.com>:
> >
> >
> > I remember looking at possibility at adding tamper resisistent hardware
> > chip to PCs back in 83 or 84 time frame (aka the TCPA idea for PCs is
> going
> > on at least 20 years old now).  It was the first time I ran into
> embedding
> > chip in a metal case that would create electrical discharge frying the
> chip
> > if the container was breached.
> >
> > Remember when applications came with their own copy-protection floppy
> > disks? .... it was possible to build up a library of such disks ....
> > requiring all sorts of remove, search, insert ... when switching from one
> > application to another. They eventually disappeared ... but imagine if
> they
> > had survived into the multitasking era .... when it would have been
> > necessary to have multiple different copy protection floppy disks crammed
> > into the same drive at the same time. The chip was suppose to provide an
> > analog to the CPU serial number used for licensing software on mainframes
> > .... dating at least from the original IBM 370s (store cpuid hardware
> > instruction).
> >
> > Some of the higher-end applications still do that with some form of
> dongle
> > (originally in the serial port) that comes with the application .... it
> > doesn't quite have the downside of trying to cram multiple floppies into
> > the same drive concurrently; the serial port dongles allow for them to be
> > inline cascaded ... and in theory still be able to use the serial port
> for
> > other use at the same time.
> >
> > i believe that there is some statistic some place about the UK and the US
> > are really great .... that in those two countries the copyright piracy is
> > estimated to only be 50 percent.
> 
> --
> Ryan Lackey [RL7618 RL5931-RIPE]        ryan at havenco.com
> CTO and Co-founder, HavenCo Ltd.        +44 7970 633 277
> the free world just milliseconds away   http://www.havenco.com/
> OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F
> 
> 
> 

-- 
Ryan Lackey [RL7618 RL5931-RIPE]        ryan at havenco.com
CTO and Co-founder, HavenCo Ltd.        +44 7970 633 277 
the free world just milliseconds away   http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com