
Lucky Green wrote :
Actually, it is 10 million keyboards with smartcard readers. Unless Intel increased the lot size. I talked with a person at Intel attempting to purchase the devices back in October, 1996. He expressed the difficulties they were having finding a keyboard vendor who understood that the CPU should not be directly involved in the smartcard operation. From this discussion, I assumed the purpose of the devices is authentication.
The keyboards might be for an ecommerce solution or they might be used in conjunction with Intel's P7, which will support encrypted instruction sets.
I find the notion of an extremely wide deployment (as any Intel x86 product will be) of machines with processors that support encrypted instruction sets and associated smart cards deeply disquieting. It seems to me that this is enabling technology that would allow the insertion of autonomous encrypted 'little brothers', into operating systems and perhaps major net applications such as web browsers as well.. These 'little brother' observers could be made completely opaque to even determined and sophisticated users - with encrypted code and the potential for encryption of all their data it would require breaking the encryption for an independant entity to understand what such an agent was doing and who it was doing it for. And by making support of such agents part of the encrypted inner ring of an OS (Win99?), it might be very nearly impossible to run the OS without the agent or agents present and operating properly. And as more and more PCs are net connected, such agents would not need to operate entirely autonomously, as they could communicate over encrypted links with their Big Brother somewhere else. The sea change in computing that would result from providing a mechanism for secret, black box, unknowable and unalterable code to run on the worlds personal computers is very significant. Up to now it has been possible, with effort and skill and intelligence, to determine what the code of any OS or application did by decompiling it, or use of software ICEs, debuggers, and even hardware monitors such as ICE's and logic analyzers. Presumably an encrypted Intel processor will reveal these secrets only to a very limited group of trusted developers, and perhaps even then only information about the application or layer the person is authorized to work on. Having both the ability to know what code is doing, and the ability to alter it has so far detered most attempts to put unfriendly agents into OS or applications code. It has been too easy to discover them, and too easy to disable them for this to be a really effective tool of social control, as witnessed by the failure of generations of copy protection schemes. But a truly secure encrypted processor changes things a lot - both understanding what the code does and modifying it become near impossible. While one can readily understand and even sympathize with the use of such entities to control and perhaps even largely eliminate software piracy and other theft of intellectual property, the potential uses of secure agents to implement more sinister social policy are frightening. A three way encrypted handshake between an encrypted agent that was part of the OS and a smart card and software at an ISP could be used to enforce an internet drivers license law for example, with no packets being forwarded by the ISP without hard authentication (even up to biometrics) of the user. And it would be rather trivial to disallow use of "unapproved" software to communicate over the net, making enforcement of GAK much more complete. One could even use such a mechanism to forbid use of any uncertified software on a net connected machine, thus making it rather hard to use such rogue applications as PGP. And given that independant review of such secret OS code would be near impossible, adding a Digital Telephony style watcher that could be turned on via an encrypted packet from the net to record the user's actions and what he typed or even access encryption keys or plaintext of encrypted traffic would simply require collusion between the OS supplier and the government, perhaps under pressure of antitrust enforcement or other suitable incentivization. Discovering that such a secret trojan was in the encrypted inner kernal code would not be easy, especially if it was only used rarely... Perhaps most sinister, as more and more of the code run on a PC becomes encrypted and opaque, it gets easier and easier for a trojan created not by a Big Brother state, but by criminal elements or foreign or industrial spies, to hide amidst all the other layers of encrypted code, safe from being detected by all but the few in possesion of the master keys or special hardware required to understand what was going on. Dave Emery die@die.com