Security via hardware?

Discussion in 'Computer Security' started by Michael Pelletier, Apr 30, 2005.

  1. Michael Pelletier, Apr 30, 2005
    #1
    1. Advertising

  2. Michael Pelletier

    nemo_outis Guest

    nemo_outis, Apr 30, 2005
    #2
    1. Advertising

  3. nemo_outis wrote:

    > Michael Pelletier <> wrote in news:C%Qce.2686
    > $_K.759@fed1read03:
    >
    >> http://www.securityfocus.com/news/11005?ref=rss

    >
    >
    >
    > Microsoft is NOT your friend. The classic critique of Palladium, TC /
    > TCG / LaGrande / NGSCB / Longhorn / Palladium / TCP or whatever name it
    > morphs into to escaope its bad PR is by the famous Ross Anderson:
    >
    > http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
    >
    > Regards,


    WOW...

    --

    "Microsoft isn't evil, they just make really crappy operating systems." -
    Linus Torvald
     
    Michael Pelletier, Apr 30, 2005
    #3
  4. Michael Pelletier <> writes:
    > http://www.securityfocus.com/news/11005?ref=rss


    one of the security models is PAIN:

    * Privacy
    * Authentication
    * Identification
    * Non-repudation

    there is the 3-factor authentication model
    http://www.garlic.com/~lynn/subpubkey.html#3factor

    * something you know
    * something you have
    * something you are

    the "something you know" authentication have frequently been
    shared-secrets ... pins, passwords, account numbers, etc. There is
    frequently a recommendation that people are required to have a unique
    shared-secret for every domain they operate in. The vulnerability is
    that people that are part of one security domain infrastructure not
    only can use the information to authenticate you in one security
    domain ... they can also use the same information to impersonate you
    in another security domain (i.e. pin/password used with your local
    neighborhood ISP isn't likely to be the same pin/password you use for
    online banking or at your place of employment).

    the use of static ("shared-secret") paradigm for authentication has
    led to crooks harvesting both information in flight ... as well as
    large repositories of information at rest. At lot of this has been
    hitting the news recently with regard to identity theft. Nominally,
    identity theft is obtaining enuf (static) information about you to
    open new accounts in your name. It is also being used to obtain
    any information necessary that enables them to perform fraudulent
    transactions with your existing accounts. an example in discussion
    of security proportional to risk:
    http://www.garlic.com/~lynn/2001h.html#61
    other random stuff with respect to shared-secret infrastructures
    http://www.garlic.com/~lynn/subpubkey.html#secrets

    in any case, it has given rise to many people having scores of
    pin/passwords that they have to keep track of ... which frequently
    leads to them all being record on a piece of paper (or in a file) that
    is subject to be stolen (or copied).

    In any case, all of this has given rise to other authentication
    mechanisms ... including "something you have" (frequently chips that
    have some unique characteristic which is difficult to counterfeit) or
    "something you are" (biometrics). Ideally, in either of these other
    paradigms, you no longer need a unique thing per security-domain for
    instance it is unlikely that you are going to be issued a unique thumb
    in lieu of every existing unique password you may currently have (with
    tokens of sufficient integrity characteristics ... you shouldn't also
    need to be issued a unique token in lieu of every existing unique
    password). The advantage of unique thumbs or tokens ... is that they
    are much harder to counterfeit than shared-secret pin-passwords (and
    proof of token possession shouldn't be dependent on generation of
    static data which can be skimmed and later replayed for
    impersonation).

    So one of the PC hardware proposals was to put a "something you have"
    hardware token chip that performed authentication using some kind of
    dynamic data ... that couldn't simply be harvested or skimmed
    (evesdropping) for later impersonation and/or fraudulent purposes.
    Your applications running on your PC could utilize the chip in
    internet authentication protocols on your behalf.

    Unfortunately several other market forces complicate such deployment.
    In the IBM unbundling of june 23rd, 1969 ... IBM announced that it was
    going to start charging for software (motivated quite a bit because of
    litigation from the fed. gov. and other entities). At first, it was
    just application software where kernel software continued to ship as
    "free". In order to appropriately charge for each copy of software
    being used, each copy was installed on a machine referencing a unique
    processor serial number (in effect, if you didn't enforce a customer
    to pay for each copy they were using ... you might be still be
    considered guilty of bundling software and hardware).

    eventually the legal forces (especially from the federal gov) to
    enforce separate charging for hardware and software began to permeate
    much of the rest of the industry. a cornerstone of the software
    pricing was to be able to uniquely associated each copy of software
    with its use. One way of doing that was having each processor uniquely
    identified.

    in the early 80s, there was some of this permeating the PC industry
    .... sometimes referred to under the heading of DRM (digital rights
    management). The PCs of the period didn't have unique,
    non-counterfeitable identification. The mechanism used was to ship a
    unique and (supposedly) non-counterfeitable (and non-copy'ble) floppy
    disk. You could install the application on your hard disk ... but the
    application required a specific floppy disk to be in the reader in
    order for it to operate.

    One such view ... if it is possible to create a unique authentication
    mechanism for each PC ... system and application software might also
    be able to use it to make sure that it was running on the machine that
    it was supposed to be running on (the mainframe model introduced in
    the 70s when litigation forced unbundling ... being applied to the PC
    market).

    This might be considered to be slightly more appearling than having
    every system component and application ship with its own unique USB
    (chip) token ... and the associated component/application wouldn't
    operate unless the associated USB token was currently plugged in
    (i.e. the mid-80s DRM model substituting non-copy'able and
    non-counterfietable chips for non-copy'able and non-counterfeitable
    floppy disks) ... if managing scores of different passwords was
    difficult ... imagine trying to concurrently manage hundreds of
    unique USB tokens for every machine.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
     
    Anne & Lynn Wheeler, May 1, 2005
    #4
  5. Michael Pelletier

    bowgus Guest

    H/W implemented security is imo perfect for business, goverment(s) ... but
    not appropriate for the home use. Geez ... just finding the car keys is
    tough some mornings :)


    "Michael Pelletier" <> wrote in message
    news:C%Qce.2686$_K.759@fed1read03...
    > http://www.securityfocus.com/news/11005?ref=rss
    >
    > --
    >
    > "Microsoft isn't evil, they just make really crappy operating systems." -
    > Linus Torvald
     
    bowgus, May 1, 2005
    #5
  6. Michael Pelletier

    Jim Watt Guest

    On Sun, 1 May 2005 01:03:24 -0400, "bowgus" <> wrote:

    >H/W implemented security is imo perfect for business, goverment(s) ... but
    >not appropriate for the home use.


    Part of the problem is that home and work computers are the same
    these days so people expect to be able to do things on their work
    computers they really should not.

    However I suspect all this is more geared to DRM for music and
    film content than stopping people downloading cool tool bars and
    fancy cursors.

    Yet another threat is the inclusion of a unique identifier and
    protected storage for cryptographic purposes in the specification
    of hard disks, so digital content can be locked to a particular drive.

    What fun when it crashes ...
    --
    Jim Watt
    http://www.gibnet.com
     
    Jim Watt, May 1, 2005
    #6
  7. Michael Pelletier

    Winged Guest

    Anne & Lynn Wheeler wrote:
    > Michael Pelletier <> writes:


    > This might be considered to be slightly more appearling than having
    > every system component and application ship with its own unique USB
    > (chip) token ... and the associated component/application wouldn't
    > operate unless the associated USB token was currently plugged in
    > (i.e. the mid-80s DRM model substituting non-copy'able and
    > non-counterfietable chips for non-copy'able and non-counterfeitable
    > floppy disks) ... if managing scores of different passwords was
    > difficult ... imagine trying to concurrently manage hundreds of
    > unique USB tokens for every machine.


    Interesting article however hardware encryption doesn't work on several
    levels. Certain CAD vendors use hardware locks that slow the
    redistribution of applications, but does not stop it from occurring.
    Usually some bright boy writes a mod to bypass the key in use.
    Sometimes this requires a driver or a modification of the code.
    The processor serial number method also has issues, for the same reason.
    DRM software has issues on many levels and it too can be thwarted
    without extensive effort. The key is if you distribute code it is open
    to compromise. As long as one can monitor the exit and entry points, one
    can foil the system.

    On authentication, I am only aware of few biometric device that work
    reliably. I have used a wide variety of commercial systems and all have
    various issues, for example, one iris identification system I have
    worked with , did not work reliably, same for a retina scan system used,
    depending on the day, and even time of day, it frequently denied access
    to what I needed access to.

    At the other end of the spectrum, my fingerprint ID system on my laptop,
    lets my daughter into the system more reliably than me, go figure.

    I have used a palm access system that worked well, near as I could tell,
    that also used a pin, and seem to know who I was, but I don't know if
    other palms may have worked if they had known the pin, it wasn't an area
    I was allowed to experiment in,in fact experimentation was discouraged
    with vigor, but the system allowed me in very reliably, irrespective of
    cuts or other hand issues. I suspect the guys wearing the guns behind
    the glass might have been a critical key to success of that system.
    They knew everyone who was normally allowed access, and checked IDs on
    entry/exit, and according to signage, authorized to use lethal force (I
    am not aware that was ever tested). The biggest flaw for that system I
    suspect was cost (at the time, reputed cost was 7 figures).

    Various smart card techniques work reasonably well, as well as
    electronic sequencers (small card device that generates a 12 digit alpha
    numeric number every few minutes, which also require a user pass
    phrase), but heaven help you if you leave you leave your wallet at home.
    I guess that relates to the PAIN acronym.

    There is a DNA authentication system in development that provides good
    authentication, but what happens when they decide you gotta change the
    key because it has been compromised? :p

    I don't have the solution, if I did, I would be on a nice beach
    somewhere far away from ill conceived and flawed security systems. I
    know many vendors preach they have the ultimate secure system, but I
    have yet to see one that does not have the critical flaw; users.

    Winged
     
    Winged, May 1, 2005
    #7
  8. Michael Pelletier

    Winged Guest

    bowgus wrote:
    > H/W implemented security is imo perfect for business, goverment(s) ... but
    > not appropriate for the home use. Geez ... just finding the car keys is
    > tough some mornings :)
    >
    >
    > "Michael Pelletier" <> wrote in message
    > news:C%Qce.2686$_K.759@fed1read03...
    >
    >>http://www.securityfocus.com/news/11005?ref=rss
    >>
    >>--
    >>
    >>"Microsoft isn't evil, they just make really crappy operating systems." -
    >>Linus Torvald

    >
    >
    >

    Same thing applies to business and government. Hardware keys are a
    major issue to maintain and track. This also has operational
    ramifications when multiple keys are required for multiple packages.

    Winged
     
    Winged, May 1, 2005
    #8
  9. Winged <> writes:
    > On authentication, I am only aware of few biometric device that work
    > reliably. I have used a wide variety of commercial systems and all
    > have various issues, for example, one iris identification system I
    > have worked with , did not work reliably, same for a retina scan
    > system used, depending on the day, and even time of day, it frequently
    > denied access to what I needed access to.
    >
    > At the other end of the spectrum, my fingerprint ID system on my
    > laptop, lets my daughter into the system more reliably than me, go
    > figure.


    for the past several years at ID shows ... my fingerprint tended to
    not register reliably ... although it has somewhat improved within
    the last couple months. they claimed that my ridges were more
    characteristic of "asian" genotype ... lots of fine, closely spaced
    ridges (as well as lots of old abrasions; long ago and far away i
    would demonstrate macho by handling re-bars w/o gloves, back in the
    days of who could rip their shift sleave just by flexing their bicep)
    .... as opposed to european norm ... which tends to have fewer and
    larger ridges.

    one of the past arguments against using fingerprints on payments
    vis-a-vis debit cards with pins ... was how easy it was to counterfeit
    fingerprints. the counter argument was that something like 30percent
    of the people write their pins on their debit card. The comparison
    then becomes, after stealing a debit card, which is more difficult:

    1) lifting fingerprint from the card and counterfeiting fingerprint
    entry
    2) lifting a pin written on the card and counterfeiting pin entry

    biometrics usually involve fuzzy matches ... with false positives and
    negatives somewhat under control of the choice of the scoring
    threshold that is set. identification may try for a higher scoring
    match (i.e. attempting to search a collection of recorded fingerprints
    for a match) than simple authentication (attempting to determine if a
    supplied fingerprint matches the authorized fingerprint).

    In authentication, there is also the issue of security proportional to
    risk ... infrastructures may be willing to accept much lower scoring
    values for $5 transactions than they are likely to accept for $1m
    transactions. slight topic drift on security proportional to risk:
    http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

    for some payment infrastructures involving offline payment
    transactions, they've tended to focus on the single optimal fixed
    scoring threshhold value and the choice of the optimal value
    .... obfuscating that most online systems are migrating to concepts
    related to security proportional to risk .... i.e. require higher
    scoring values ... and even possibly multiple readings from multiple
    fingers for higher values (and multiple readings from multiple fingers
    might be considered an addendum to 3-factor authentication paradigm).

    and for some topic drift regarding single optimal values ... and
    old april 1st security story:
    http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
    http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
     
    Anne & Lynn Wheeler, May 1, 2005
    #9
  10. Michael Pelletier

    Stan Barr Guest

    On Sat, 30 Apr 2005 18:58:16 -0600, Anne & Lynn Wheeler <> wrote:
    >
    >in any case, it has given rise to many people having scores of
    >pin/passwords that they have to keep track of ... which frequently
    >leads to them all being record on a piece of paper (or in a file) that
    >is subject to be stolen (or copied).


    Indeed. This is becoming a big problem as PINs are used by more services.
    I just had a quick check and I have 37 assorted PINs, passwords and door
    lock numbers to keep track of. The PINs I need to keep handy, credit/
    debit cards etc. I store on a card in my wallet (with my memory I *have*
    to!) in encrypted form using a simple subtractive code.

    --
    Cheers,
    Stan Barr stanb .at. dial .dot. pipex .dot. com
    (Remove any digits from the addresses when mailing me.)

    The future was never like this!
     
    Stan Barr, May 1, 2005
    #10
  11. Michael Pelletier

    rpl Guest

    Stan Barr wrote:
    > On Sat, 30 Apr 2005 18:58:16 -0600, Anne & Lynn Wheeler <> wrote:
    >
    >>in any case, it has given rise to many people having scores of
    >>pin/passwords that they have to keep track of ... which frequently
    >>leads to them all being record on a piece of paper (or in a file) that
    >>is subject to be stolen (or copied).

    >
    >
    > Indeed. This is becoming a big problem as PINs are used by more services.
    > I just had a quick check and I have 37 assorted PINs, passwords and door
    > lock numbers to keep track of. The PINs I need to keep handy, credit/
    > debit cards etc. I store on a card in my wallet (with my memory I *have*
    > to!) in encrypted form using a simple subtractive code.
    >


    mine are my general impressions of the company's customer service, some
    are even complimentary.

    :)


    rpl
     
    rpl, May 1, 2005
    #11
  12. Michael Pelletier

    Guest

    re:
    http://www.garlic.com/~lynn/2005g.html#51 Security via hardware?

    further addenda to evolution of software pricing and licensing of
    software to specific processor (installing licensed software so that
    it only ran on a specific processor ... and software being able to
    recognize the specific processor that it had been licensed for)

    initially just applciation software was priced (and licensed for
    specifc processor) as part of the june 32rd, 1969 unbundling
    announcement (note it might have been considered a violation of the
    unbundling requirement if there was no per processor licensing
    enforced ... aka customers still effectively being able to run
    software for free).

    However, it took almost another ten years before there was kernel
    (operating system) pricing (& processor specific licensing). it
    appeared that the company was arguing that kernel software should
    continue to be free (required for correct operation of the hardware
    so remained "bundled")

    when i was an undergraduate i got involved in building a clone
    of a mainframe control unit
    http://www.garlic.com/~lynn/subtopic.html#360pcm

    later there was a write up blaming four of us for starting the
    mainframe plug compatable controller business.

    supposedly the plug-compatible controller business was one of the
    primary motivations behind the future system project. FS was going
    to more radically different from 360, than 360 had been different
    from the machines that went before it. some specific quotes
    http://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System
    other postings on FS
    http://www.garlic.com/~lynn/subtopic.html#futuresys

    FS was an extremely large project that was evnetually got killed
    before it was even announced (very few people outside the company were
    even aware of it at the time). I didn't make myself very popular
    with the FS people. There was a long running "cult" film at a
    theater down in central sq ... and I would liken a lot of FS to
    the inmates being in charge of the asylum.

    along the way, supposedly the radical departure of FS from 360 was
    contributing factor in Amdahl leaving to build 360 mainframe procssor
    clones. at a presentatio he gave at MIY in the early 70s, he was asked
    what reasoning did he use with the VC people to fund his undertaken.
    He replied that even if IBM were to completely walk away from 360 at
    that moment (can be considered a vieled referene to FS), customers had
    already invested over $100B in 360 application software, which would
    keep him in buiiness at least thru the end of the century.

    When i was an undergraduate, i was also doing a lot of operating
    system performance and algorithm work, a lot of which was picked
    up and shipped in standard product
    http;//www.garlic.com/~lynn/subtopic.html#fairshare
    http://www.garlic.com/~lynn/subtopic.html#wsclock

    in the morphing of 360 product to 370, a lot of the performance work i
    had done as an undergraduate was dropped from the product. In the
    mid-70s there was a resolution raised by the SHARE user group to have
    my performance work put back in the 370 operating systme.

    This was at a time when clone mainframe was starting to make market
    penetration. In the original unbundling, the execuse was used that
    only application software should be licensed and charged for ... that
    kernel software should still be "free" (aka bundled as part of the
    hardware) since it was necessary for the operation of the computer.

    With the advent of clone processors, the issue of not pricing and
    licensing kernel (operating system) software was revisted (aka
    customer could by their processors from clone manufactor and then get
    the operating system for free from IBM ... the clone guys did have to
    encour the significant expense associated with operating systems(.

    My "new" resource manager was selected to be the guinee pig for
    licensed/priced kernel software. I got to spend time on and off for
    six months with the business people formulating the kernel software
    pricing policies. The half-way measure taken for this round was that
    "kernel" software that was direcxtly involved in hardware support (aka
    device drivers, interrupt handlers, multiprocessor support, etc) would
    still be free; everything else could be charged for. The "resource
    manager" supposedly was better management of workload ...... so it
    wasn't directly needed for the basic hardware operation. In theory,
    customers buying large Amdahl clone machines might start paying IBM
    for some kernel software stuff.

    This did result in an unanticipated problem. I had done a lot of work
    on multiprocessor support and there was a large part of the "resource
    manager" that involved kernel restructure that had been done with
    multiprocessor support in mind. When they decided that they would
    ship multiprocessor support to customers in the next release
    http://www.garlic.com/~lynn/subtopic.html#smp
    ... they were faced with a dilemma.

    Multiprocessing support had to be "free" (under the guidelines that
    kernel code directly involved in hardware support was free) ... but it
    was dependent on a lot of the kernel reorganization code that was
    already in customer shops as part of the resource manager (which was
    charged for kernel code), The solution was creation of "new" resource
    manager ... all the code (about 80-90 percent) of the resource manager
    that was involved in kernel restructuring required by SMP support
    .... was removed and made part of the "free" kernel. The new, improved
    and drastically reduced (in number of lines of code) resource manager
    continued to be licensed at its original price.

    Along with the continued penetration of clone processors into the
    market ... there was eventually a transition to charge for all kernel
    software (whether it was required for direct hardware support or
    not)).

    for slight "security" authentication topic drift ... there was lots of
    concern regarding any information leaking out about FS.
    http://www.garlic.com/~lynn/subtopic.html#futuresys

    a super-secure online system was put together with all the
    documentation in soft copy ... people could only view the
    documentation on 3270 terminals (real terminals ... before terminal
    emulation, cut&paste, screen-scraping, etc) ... with no ability to
    print or copy the information. For various reasons they made some
    claim that even if I was in the machine room, even I wouldn't be able
    to break the security (even I?, hard not to rise to that bait). So the
    counter was that it would take less than a couple minutes. First thing
    i had to do was cut off the machine totally from any outside access
    .... and then i flipped a bit in the memory of the machine and totally
    defeated all their security. Typical authentication routine involves
    calling a routine that validates the authentication information and
    then branching based on the return code. I flipped a bit so that no
    matter what condition the validation routine returned ... everything
    would be treated as correct validation (it was a mistake to give me
    the benefit of being in the same room with the machine).

    possibly as revenge, i got assigned to help orientate the new
    company CSO that had come for some high level job at some gov.
    agency (at least in that period, CSOs coming to industry from
    a fed. gov. career had physical security background)
     
    , May 2, 2005
    #12
  13. Michael Pelletier

    andy smart Guest

    Jim Watt wrote:
    >
    > Yet another threat is the inclusion of a unique identifier and
    > protected storage for cryptographic purposes in the specification
    > of hard disks, so digital content can be locked to a particular drive.
    >
    > What fun when it crashes ...


    Point taken about the risk of a drive crash, but the same is true of
    your CD collection (which you are not legally allowed to copy)and which
    if scratched is no longer available. It is in the vendor interest
    actually to have a system for re-deploying you a copy in the event of
    such loss - the publicity for not so doing is counter productive

    Why shouldn't somebody be allowed, if they choose, to limit the copies
    of something you make; ideally you'd be allowed a backup copy for your
    own use or have an easy way to get a replacement. Just because electonic
    media of whatever type can be easily copied has given rise to the idea
    that they should be allowed to copy them easily. Locking digital content
    to a drive would make stealing additonal copies harder for the
    criminal, and the creator should be able to enforce their right to
    content ownership and distribution if they so choose IMHO
     
    andy smart, May 3, 2005
    #13
  14. Michael Pelletier

    Colin B. Guest

    andy smart <> wrote:
    > Jim Watt wrote:
    >>
    >> Yet another threat is the inclusion of a unique identifier and
    >> protected storage for cryptographic purposes in the specification
    >> of hard disks, so digital content can be locked to a particular drive.
    >>
    >> What fun when it crashes ...

    >
    > Point taken about the risk of a drive crash, but the same is true of
    > your CD collection (which you are not legally allowed to copy)and which
    > if scratched is no longer available. It is in the vendor interest
    > actually to have a system for re-deploying you a copy in the event of
    > such loss - the publicity for not so doing is counter productive


    Speak for yourself. *I* am legally allowed to copy my own CDs. Furthermore,
    I'm allowed to lend them to people, and they are allowed to copy them for
    their own use.

    > Why shouldn't somebody be allowed, if they choose, to limit the copies
    > of something you make; ideally you'd be allowed a backup copy for your
    > own use or have an easy way to get a replacement. Just because electonic
    > media of whatever type can be easily copied has given rise to the idea
    > that they should be allowed to copy them easily. Locking digital content
    > to a drive would make stealing additonal copies harder for the
    > criminal, and the creator should be able to enforce their right to
    > content ownership and distribution if they so choose IMHO


    Locking digital content to a drive would make it harder for the average
    user to make additional copies. It would NOT deter the actual criminals
    out there, making illegal copies for profit.

    All that various DRM schemes does is piss off the average consumer. It
    doesn't stop illegal commercial copying, nor protect the creator of the
    content.

    Colin
     
    Colin B., May 3, 2005
    #14
  15. Michael Pelletier

    andy smart Guest


    > Speak for yourself. *I* am legally allowed to copy my own CDs. Furthermore,
    > I'm allowed to lend them to people, and they are allowed to copy them for
    > their own use.
    >

    Sorry, my poor use of words. I meant the CDs that you own but which do
    not contain content which you yourself produced and which is under
    copyright by others.


    >
    > Locking digital content to a drive would make it harder for the average
    > user to make additional copies. It would NOT deter the actual criminals
    > out there, making illegal copies for profit.


    If the 'average user' does not have the legal right to copy the content
    then they are the actual criminal. Sorry but I feel very strongly about
    the use of lesser terms to cover illegal activity (the classic one is
    "shoplifting", what the hell is that? It's stealing, why can't we just
    use the word "stealing"?), we talk about people copying Music CDs for
    other people, well unless they have the permission from the copyright
    holder then they've stolen a copy (even if it's only a single copy).
     
    andy smart, May 3, 2005
    #15
  16. Michael Pelletier

    Arthur T. Guest

    In Message-ID:<d57tqh$l4r$>,
    andy smart <> wrote:

    >Point taken about the risk of a drive crash, but the same is true of
    >your CD collection (which you are not legally allowed to copy)and which
    >if scratched is no longer available.


    Backup copy is part of "fair use". (IANAL)

    >It is in the vendor interest
    >actually to have a system for re-deploying you a copy in the event of
    >such loss - the publicity for not so doing is counter productive


    Considering the RIAA attacks, I don't think publicity is a
    concern. When's the last time you asked for a replacement CD
    because you scratched yours? (Note: One retailer used to have a
    lifetime replacement policy. They've been bought by another
    retailer and no longer honor it.)

    >ideally you'd be allowed a backup copy for your
    >own use or have an easy way to get a replacement.


    The problem with the backup copy is that either it's tied to
    the crashed hardware (and useless), or it isn't (and could be sent
    to someone else, obviating the protection scheme).


    --
    Arthur T. - ar23hur "at" speakeasy "dot" net
    Looking for a good MVS systems programmer position
     
    Arthur T., May 3, 2005
    #16
  17. Michael Pelletier

    Leythos Guest

    On Tue, 03 May 2005 14:53:53 +0000, Colin B. wrote:
    >
    > Speak for yourself. *I* am legally allowed to copy my own CDs.
    > Furthermore, I'm allowed to lend them to people, and they are allowed to
    > copy them for their own use.


    Just to make sure we understand you, you are speaking of your own,
    personally created CD's, without any commercial content from second/third
    party?

    If you are talking about Music CD's, or DVD's with movies, that have been
    purchased inside the USA, then we can not duplicate them except for backup
    purposes.

    --

    remove 999 in order to email me
     
    Leythos, May 3, 2005
    #17
  18. Michael Pelletier

    Colin B. Guest

    andy smart <> wrote:
    >
    >> Speak for yourself. *I* am legally allowed to copy my own CDs. Furthermore,
    >> I'm allowed to lend them to people, and they are allowed to copy them for
    >> their own use.
    >>

    > Sorry, my poor use of words. I meant the CDs that you own but which do
    > not contain content which you yourself produced and which is under
    > copyright by others.


    That's what I meant as well. The key is that I'm not in the USA, and I'm
    not beholden to their laws.

    > If the 'average user' does not have the legal right to copy the content
    > then they are the actual criminal.


    Well in one case, you have a 'criminal' who is copying a purchased item
    (say a CD) to listen to if the original gets damaged. Neither actual damage
    or criminal intent are apparent here.

    In another case, the average user _does_ in fact have the legal right to
    copy the content, as explicitly guaranteed by their country's laws.

    In yet another case, you have people who are casually breaking the law to
    avoid buying material.

    In a final case, you have people who are deliberately copying material
    illegally, and possibly even profiting off of it.

    DRM will stop the first three of these, only one of which is harmful.
    It will not stop the last one, which is the most harmful of all. In other
    words, DRM fails in 3/4 of the test cases here.

    > Sorry but I feel very strongly about
    > the use of lesser terms to cover illegal activity (the classic one is
    > "shoplifting", what the hell is that? It's stealing, why can't we just
    > use the word "stealing"?),


    I think you're overreacting. Shoplifting isn't a 'lesser term,' it's a
    specific category of stealing, with its own detailed pieces of law.

    > we talk about people copying Music CDs for
    > other people, well unless they have the permission from the copyright
    > holder then they've stolen a copy (even if it's only a single copy).


    Stealing has never been an appropriate word to be applied to copyright
    infringement, via copying. Stealing implies that I take something away from
    you, and you don't have it anymore. Copying means that I take something
    and you still have it.

    Look, I'm a strong believer in rational copyright protection. I buy my
    music, I buy my software, I buy my movies. However, DRM is simply not the
    right way to protect copyright--it's both flawed in its implementation, and
    limited in its ability to express laws. Copyright is a legal protection--it
    should be upheld and maintained through legal means, not technical ones.

    Colin
     
    Colin B., May 3, 2005
    #18
  19. Michael Pelletier

    Guest

    so
    http://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
    http://www.garlic.com/~lynn/2005g.html#54 Security via hardware?
    http://www.garlic.com/~lynn/2005g.html#55 Security via hardware?

    had trusted ID type support ... but not for actually building a
    trusted system ... but for the evolving software pricing & licensing
    infrastucture ... similar to current day DRM issues.

    in the 60s & 70s we had built secure multi-user timesharing systems
    .... significantly more secure than many of the systems out there
    today. the security of these systems weren't dependent on hardware
    identification ... but basically from the ground-up builtin security
    design. some of this is referenced in past posts about commerical
    multi-user, timesharing systems from the 60s & 70s
    http://www.garlic.com/~lynn/subtopic.html#timeshare

    recent post about specific example where cambridge
    http://www.garlic.com/~lynn/subtopic.html#545tech
    was already providing some general access to various BU, MIT, Harvard,
    and other students in the Cambridge area ... and then with the advent
    of cms\apl, cms\apl system file i/o capability and really "large"
    workspaces ... corporate hdqts people loaded some of the most valuable
    corporate data on the machine for doing business modeling.
    http://www.garlic.com/~lynn/2005g.html#27 Moving assembler programs
    above the line

    one might even make an assertion that to some extent the orange book
    work was attempting to capture some of the characteristics of these
    earlier systems and have it apply to later/newer
    commerical-off-the-shelf endevors. a couple recent, slightly related
    posts:
    http://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration
    standard
    http://www.garlic.com/~lynn/2005g.html#38 MVS secure configuration
    standard
    http://www.garlic.com/~lynn/2005g.html#40 MVS secure configuration
    standard
    and
    http://www.garlic.com/~lynn/2005g.html#48 Best practices" or "Best
    implementations"?
    http://www.garlic.com/~lynn/2005g.html#49 Best practices" or "Best
    implementations"?
    http://www.garlic.com/~lynn/2005g.html#53 Best practices" or "Best
    implementations"?

    the other application for trusted system identification ... is not so
    much whether a system is built with high level of integrity .... but
    if a system asserts such a characteristic to a remote operation
    .... how much trust can the remote operation place in the integrity
    assertion. This is similar to the EU finread terminal standard.
    http://www.garlic.com/~lynn/subpubkey.html#finread

    the standard specifies a number of integrity characteristics for
    finread ... however the standard doesn't actually specify a mechanism
    where a remote, relying party has any assurance that a finread was
    actually used via-a-vis some counterfeit terminal. one of the things
    in the x9.59 financial standard
    http://www.garlic.com/~lynn/index.html#x959

    allowed for the terminal digital signing a transaction in addition to
    the end user. the user's digital signature provides some
    authentication about the originating party (aka verification of the
    digital signature with a public key implies "something you have"
    authentication, aka the originating entity has access and use of the
    corresponding private key) ... the terminal digital signature provides
    some indication as to some integirty characteristics of the digital
    signing environment (was a finread standard terminal in use).

    In that sense, a trusted machine authentication mechanism may not only
    provide reference for licensed software running on the local machine
    .... but possibly also a kind of reference for distributed licensing
    infrastructures.

    There have been various infrastructure definitions for really personal
    computing devices ... where a trustest mashine authentication not only
    services as the scaffolding for software (and other kind of licensing
    .... aka DRM) licensing ... but also as authenticating the device owner
    .... in lieu of a separate personal authentication token.

    This does start to trample on the institution-centric token vis-a-vis
    person-centric token paradigms. In the institutional centric paradigm
    .... each institution provides each individual with a unique token
    (basically one-for-one replacement for existing shared-secret
    pin/password). In the person-centric token paradigm ... the individual
    registers their personal token(s) with each institution.

    In the 90s, we were looking at the end-to-end business process
    associated with token authentication infrastructure as well as trying
    to significantly achieve cost-reductions. On of the big expensive
    items in the institutional centric model is typically there
    personalization that an institution performs for every
    token. Elimination of institutional personalization can significantly
    reduce costs in a token-based "something you have" infrastructure.
    Soemtimes this streamlining can represent as much as a 10-to-one cost
    reduction.

    More interesting ... in moving away from institutional token
    personalization can also enable the transition to person-centric token
    infrastructure ... rather than every institution personalizing a
    unique token for every person ... a person registers their token(s)
    with every institution. If you assume a transition to an
    insitution-centric token system with each person have a unique token
    in place of every existing pin/password ... then a 10:1 reduction in
    token infrastructure costs is significant (by streamlining the
    infrastructure delivery costs). however, if you assume that every
    person eventually requires an avg. of one hundred tokens, then a
    transition from an institutional-centric model to a person-centric
    model can represent a 100:1 reduction in the number of tokens ... with
    a corresponding 100:1 reduction in infrastructure token costs. A
    combination of 10:1 reduction in per token cost plus a 100:1 reduction
    in token number costs ... would represent an overall 1000:1 cost
    reduction in token infrastructure related costs.

    if one were considering the 3-factor authentication model

    * something you have
    * something you know
    * something you are

    a transition from a per institution "something you have" token for
    every person to a person-centric "something you have" token could
    be considered making token paradigm closer aligned with biometric
    paradigm (as long as it is unique ... a unique thumbprint per
    institution isn't required)

    misc past person/individual centric authentication infrastructures
    http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst
    case, or average case? (TCPA)
    http://www.garlic.com/~lynn/2004q.html#0 Single User: Password or
    Certificate
    http://www.garlic.com/~lynn/2005g.html#8 On smartcards and card readers
    http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for
    smartcards

    lots of past AADS references
    http://www/garlic.com/~lynn/index.html#aads

    lots of past posts on general assurance issues
    http://www.garlic.com/~lynn/subpubkey.html#assurance

    general past posts on exploits, vulnerabilities, fraud, etc
    http://www.garlic.com/~lynn/subpubkey.html#fraud

    some specific past posts on common buffer overflow exploits
    http://www.garlic.com/~lynn/subpubkey.html#overflow

    random past posts mentioning TCPA &/or palladium
    http://www.garlic.com/~lynn/aadsm11.htm#47 maximize best case, worst
    case, or average case? (TCPA)
    http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium
    detractors
    http://www.garlic.com/~lynn/aadsm12.htm#15 Challenge to TCPA/Palladium
    detractors
    http://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium /
    TCPA
    http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential
    downside of TCPA
    http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential
    downside of TCPA
    http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable
    during ownership change (Re: Overcoming the potential downside of TCPA)
    http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge
    http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
    http://www.garlic.com/~lynn/aadsm16.htm#10 Difference between
    TCPA-Hardware and a smart card (was: example:secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm16.htm#15 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before
    http://www.garlic.com/~lynn/aadsm16.htm#19 Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before
    http://www.garlic.com/~lynn/aadsm16.htm#20 Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before
    http://www.garlic.com/~lynn/aadsm16.htm#21 Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before
    http://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before
    http://www.garlic.com/~lynn/aadsm16.htm#24 Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before
    http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)<
    http://www.garlic.com/~lynn/aadsm17.htm#1 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between
    TCPA-Hardware and a smart card (was: examp le: secure computing kernel
    needed)
    http://www.garlic.com/~lynn/aadsm18.htm#48 Dell to Add Security Chip to
    PCs
     
    , May 3, 2005
    #19
  20. Michael Pelletier

    Colin B. Guest

    Arthur T. <> wrote:
    > In Message-ID:<d57tqh$l4r$>,
    > andy smart <> wrote:
    >
    >>Point taken about the risk of a drive crash, but the same is true of
    >>your CD collection (which you are not legally allowed to copy)and which
    >>if scratched is no longer available.

    >
    > Backup copy is part of "fair use". (IANAL)


    Owning one is covered under fair use. Creating one is still up in flux in
    the USA.
     
    Colin B., May 3, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. COMSOLIT Messmer

    IT-Security, Security, e-security

    COMSOLIT Messmer, Sep 5, 2003, in forum: Computer Support
    Replies:
    0
    Views:
    640
    COMSOLIT Messmer
    Sep 5, 2003
  2. ChrisR
    Replies:
    10
    Views:
    1,121
    Ivor Jones
    Apr 26, 2005
  3. Paulmw
    Replies:
    0
    Views:
    555
    Paulmw
    Jan 11, 2004
  4. QUIROGACA
    Replies:
    1
    Views:
    749
    Walter Mautner
    Nov 14, 2006
  5. QUIROGACA
    Replies:
    2
    Views:
    596
    Walter Mautner
    Nov 14, 2006
Loading...

Share This Page