Security via hardware 535
of btract a hundred and four for e-mail. Only if you had to have each binary on the system to be able to run on every...
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, pbuttwords, 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-pbuttword used with your local neighborhood ISP isn't likely to be the same pin-pbuttword you use for online banking or at your place of employment).
This is true, because you might go to that other place, you just don't know...
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 idenbreasty theft. Nominally, idenbreasty 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
so 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...
in any case, it has given rise to many people having scores of pin-pbuttwords 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 pbuttword 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 pbuttword). The advantage of unique thumbs or tokens ... is that they are much harder to counterfeit than shared-secret pin-pbuttwords (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.
misc. references the issue isn't worrying about the certification of who is using an authentication hardware token .... since there are huge number of existing business processes that are related...
Unfortunately several other market forces complicate such deployment. In the IBM unbundling of june 23rd, 1968 plus 1 ... IBM announced that it was going to start charging for software (motivated quite a bit because of litigation from the fed. gov. and other enbreasties). 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 buttociated 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 buttociated component-application wouldn't operate unless the buttociated USB token was currently plugged in (i.e. the mid-80s DRM model subsbreastuting non-copy'able and non-counterfietable chips for non-copy'able and non-counterfeitable floppy disks) ... if managing scores of different pbuttwords was difficult ... imagine trying to concurrently manage hundreds of unique USB tokens for every machine.
--