>Although desirable, such requirements can be prohibitive due to >costs. Also there is a problem with "trust" because trust and >authenticated are not equivalent.
Understood. However, authentication is a requirement for trust. We has to solve that problem before we can solve the trust issue. >This automatic trust of things or people that you never had any >previous contact with is a "wet dream" that PKI promoters have pushed >in vain. Things don't work this way. I never said I believed in 100% trust. I don't believe in 100% authentication either. >Better way: Let the financial trust network handle ATM-to-bank >authentication. This is probably how it is done today. Yes. They do use some clever crypto, and it's audited, and good stuff. But it sometimes is security though obscurity, and there is a danger that there is a flaw in the system. And ATM machines have been hacked. Crooks put mag strip sniffers in the slot, and pinhole camera to capture the PIN. They've also used keypad overlays to steal PINs. So ATM's are NOT secure. Also - this requires a closed authentication system that prevents application interoperability. >Bad way: Having the user / card / device recognize the >authenticity of ATM. Using PKI that would require the >root(s) of ATM PKIs be carried around. Will not happen. Ever. Why not? Let's say I want to do business with bank XYZ. So I get a certificate from their CA, and put it in my trust store in the card. Now if I approach a strange ATM, and it provides be a signed certificate by bank XYZ's CA, I can trust it as much as I trust the Bank's CA and the trust of its signing process. This prevents the problem of going up to a strange ATM, and having your card stolen or replicated. Same issue with web sites that want your credit card number. I believe some of the cards can verify the identity of the site (and prevent phishing, etc.) So there is a definate need for certificates, and certificate authorities. As I see it, NFC, or rather, any sort of integrated ID management, will never be "killer technology" unless these sorts of issues are resolved. Until then, we will always be limited to single-function solutions. _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
