It's flat-out impossible to make a "trusted platform" assertion. (Reference Apple's OSX-Intel debacle when hackers just bypassed the trusted chip in its software. Reference also the DVD encryption mechanism.)
When the hardware is physically in control of a user, it cannot be deemed 'secure' under any hypothesis. This is what 'security' is -- making it difficult for someone who's not authorized to get into a sensitive area, while simultaneously making it not too cumbersome for someone who is authorized to get into that area. 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. (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.) Security is "limiting the damage that a malicious security principal can do". A running computer OS installation is a security principat. 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. Information security is certainly necessary, but demanding a platform attestation is non-viable (keyloggers? network sniffers? debugging privileges? Ability to run arbitrary programs?). -Kyle H 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
