Security via hardware?

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

  1. Michael Pelletier, Apr 30, 2005
    1. Advertisements

  2. Michael Pelletier

    nemo_outis Guest

    nemo_outis, Apr 30, 2005
    1. Advertisements

  3. WOW...
    Michael Pelletier, Apr 30, 2005
  4. one of the security models is PAIN:

    * Privacy
    * Authentication
    * Identification
    * Non-repudation

    there is the 3-factor authentication model

    * 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:
    other random stuff with respect to shared-secret infrastructures

    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

    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

    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

    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, May 1, 2005
  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 :)
    bowgus, May 1, 2005
  6. Michael Pelletier

    Jim Watt Guest

    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, May 1, 2005
  7. Michael Pelletier

    Winged Guest

    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, May 1, 2005
  8. Michael Pelletier

    Winged Guest

    Winged, May 1, 2005
  9. 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
    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: 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: OT Re: A beautiful morning in AFM. OT Re: A beautiful morning in AFM.
    Anne & Lynn Wheeler, May 1, 2005
  10. Michael Pelletier

    Stan Barr Guest

    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.

    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
  11. Michael Pelletier

    rpl Guest

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


    rpl, May 1, 2005
  12. Michael Pelletier

    lynn Guest

    re: 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

    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 FS - IBM Future System
    other postings on FS

    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

    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
    ... 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

    for slight "security" authentication topic drift ... there was lots of
    concern regarding any information leaking out about FS.

    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)
    lynn, May 2, 2005
  13. Michael Pelletier

    andy smart Guest

    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
  14. Michael Pelletier

    Colin B. 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.
    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

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

    andy smart Guest

    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.

    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
  16. Michael Pelletier

    Arthur T. Guest

    In Message-ID:<d57tqh$l4r$>,
    Backup copy is part of "fair use". (IANAL)
    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.)
    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., May 3, 2005
  17. Michael Pelletier

    Leythos Guest

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

    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
    Leythos, May 3, 2005
  18. Michael Pelletier

    Colin B. Guest

    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.
    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.
    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.
    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 B., May 3, 2005
  19. Michael Pelletier

    lynn Guest

    so Security via hardware? Security via hardware? 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

    recent post about specific example where cambridge
    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. 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: MVS secure configuration
    standard MVS secure configuration
    standard MVS secure configuration
    and Best practices" or "Best
    implementations"? Best practices" or "Best
    implementations"? Best practices" or "Best

    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.

    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

    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

    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

    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 maximize best case, worst
    case, or average case? (TCPA) Single User: Password or
    Certificate On smartcards and card readers Maximum RAM and ROM for

    lots of past AADS references

    lots of past posts on general assurance issues

    general past posts on exploits, vulnerabilities, fraud, etc

    some specific past posts on common buffer overflow exploits

    random past posts mentioning TCPA &/or palladium maximize best case, worst
    case, or average case? (TCPA) Challenge to TCPA/Palladium
    detractors Challenge to TCPA/Palladium
    detractors Feasability of Palladium /
    TCPA Overcoming the potential
    downside of TCPA Overcoming the potential
    downside of TCPA TCPA not virtualizable
    during ownership change (Re: Overcoming the potential downside of TCPA) A challenge A challenge Difference between
    TCPA-Hardware and a smart card (was: example:secure computing kernel
    needed) Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed) Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed) Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed) Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before Ousourced Trust (was Re:
    Difference between TCPA-Hardware and a smart card and something else
    before Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed)< Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed) Difference between
    TCPA-Hardware and a smart card (was: example: secure computing kernel
    needed) Difference between
    TCPA-Hardware and a smart card (was: examp le: secure computing kernel
    needed) Dell to Add Security Chip to
    lynn, May 3, 2005
  20. Michael Pelletier

    Colin B. Guest

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

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.