Hi Kyle, c-i-l
>It's flat-out impossible to make a "trusted platform" assertion. It is hard to see why Microsoft, Cisco and the IETF have all come out with "standards" in this space if this is a "universal truth". >(Reference Apple's OSX-Intel debacle when hackers just bypassed the >trusted chip in its software. A platform attestation would (should at least) reveal that the user does not run a genuine OSX, but a "hacked" version. >When the hardware is physically in control of a user, it cannot be >deemed 'secure' under any hypothesis. AFAIK, the operating system and boot *can* be protected by a TPM. What TPMs cannot protect against is tapping of data from the screen or keyboard using visual or HW methods. For enterprise machines this limitation seems reasonable. If a user want to screw up for himself by manipulating the hardware, is probably not in scope. It appears that TPMs and trusted boot also can protect against data mining in stolen computers. <snip> >Any protocol can be implemented on any hardware. This means that any >protocol can be emulated on any hardware, as well, as a self-evident >corollary. Agreed. > (This is why we have smart cards... so that the >information necessary to complete the protocol [i.e., the private key] >cannot be easily deduced or recovered for emulation.) TPM does exactly that for not only the machine but for any number of user keys with an added system cost of about 50 cents. What happens when you stick your s.c. "secure" smart card in a non-secure machine? It may steal your PIN and do "interesting" things in the background. TPMs will limit users' ability to use secure functions while having non-trusted software running. Note: You may indeed run untrusted software on your company machine but you will have to shut it down when you want to work (=access company resources). >Security is "limiting the damage that a malicious security principal >can do". A running computer OS installation is a security principal. >A user is a security principal. Processes are becoming security >principals. (IE, Opera, Firefox, other web browsers can and do have >exploitable bugs which can render the user's and machine's credentials >useful to software designed to abuse the circumvented access >controls.) All of these things are important to the overall security >of a system, and how much trust one can place on that system. Thus, >on the VPN, only grant access to a certain server which contains the >information necessary for the employee on the VPN connection, and to >the webmail server. Set up a different authentication mechanism for >outbound emails (it's another password for the user to have to enter, >but it would prevent things like Melissa from spreading). Lock >everything else down. But doesn't everybody hate multiple credentials and auth methods? Melissa spreaded because the SMTP auth scheme is brain-dead allowing anybody to impersonate anybody. Blaming Outlook as some people do, is IMHO wrong, even if it has been bug-riddled, since it is really SMTP that makes the bugs so "useful". Phishing and Spam are other examples of PITAs that thrive due to SMTP deficiencies. >Information security is certainly necessary, but demanding a platform >attestation is non-viable (keyloggers? network sniffers? debugging >privileges? Ability to run arbitrary programs?). Compared to securing SMTP, I remain fairly optimistic. -Anders On 7/17/06, Julien Pierre <[EMAIL PROTECTED]> wrote: > Anders, > > Anders Rundgren wrote: > > Another reason why SSL client authentication may go bust is that it does > > not support the inclusion of platform attestations, something that may be required when TPMs become standard. That is, you may [in the future] not be able to access corporate web-mail (or other sensitive web apps), from a machine that does not appear to run a "safe" operating system. Some organizations may not allow employees to access web-mail from an unknown machine even if it is "safe". Alternative authentication mechanisms, typically riding on top of an SSL channel, can with ease provide platform attestations together with the authentication response. > > Does that "platform attestation" really belong at the transport level ? > > It seems like such a repugnant idea anyway. Services like webmail are > supposed to be usable from any browser, on any computer, on any OS. > That's why they are successful in the first place. This kind of lock > certainly belongs in a proprietary client-server system, but for use on > the open Internet, I'm skeptical. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
