On Tue, 06 Jul 2010 21:27:52 EDT, Mary and Glenn Everhart said: > (Several paragraphs inventing a new protocol elided) Why do you go through all the effort of handwaving a new and untested way to establish a secure communications channel from your token to the other end, when you could just say "we diffie-hellman a session key across and use it to encrypt everything after that" and be done with it?) It's of course a tad more complicated than that - you want to also do the moral equivalent of an SSL certificate check in *both* directions, so the token knows it's talking to the desired destination and not a fake one, and vice versa. This is stuff you'd usually do in the browser, but you can't because the browser is potentially compromised and thus untrusted. Oh, and you're going to want to have sane proper CRL checking as well. This is stuff you'd usually do in the browser, but you can't because the browser is potentially compromised and thus untrusted. Oh fuck, that token just sprouted OpenSSL because we don't trust the local system's copy anymore, and it just got a bit bigger. That theme is going to come back and bite us some more later... > However the details are less important than the question: what would be > needed to achieve e-commerce systems and protocols that can function > even in the presence of infected > systems and that make it clear,when something interferes, that the > protocol has failed and that the transaction must be redone? Since we're assuming that the local hardware/software is no longer trusted, we have a problem - untrusted means we can't allow it to ever see the information in plaintext, because then it can be screen-scraped or otherwise snarfed up. We've already seen banking trojans that rewrite the bank statement on the fly to cover its withdrawals - if it pilfered $78.34, that line item won't show up on the screen and all the other numbers are adjusted so you still think you have $78.34 more than you really do. So we *really* can't let that untrusted computer ever see any of that sensitive info in cleartext. But that's OK, because we've OpenSSL'ed a secure connection from the token to the remote end. The issue is that if you want to do anything interesting like actually *display* your bank statement webpage, it can't be done on the hacked machine's display, it has to go back to the token and be displayed there. Oh fuck, the token just sprouted a web browser, a display, and an input device, because we don't trust the local system's stuff, and got even bigger. At that point, that token is pretty autonomous, and isn't using the resources of the compromised computer for anything other than just being another router of packets. So why not just make it a bit bigger, put an RJ45 or wireless on it, and unplug the hacked box and plug your token into the net instead? Oh fuck, we've just re-invented a smartphone. ;) > Can anything be done without hardware? (I have my doubts, having found > ways only that are good for a few uses before they get compromisable.) > If hardware is needed, what is the > simplest and most effective system that can be used? What would it look > like? Can it be used by most people? Seems like a hell of a lot of work to avoid having to admit we need to actually *fix* those 140 million zombied machines. Just sayin',
Attachment:
pgpl41pbpXG0T.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/