RE: [Full-disclosure] Most common keystroke loggers?

[Lyal Collins]

Title: Message

There are 3 obvious problems with this I think, although there are some good ideas embedded in this model.

Firstly, the user ID isn't used anywhere, although its captured.

Second, this is still subject to a mitm attack.

Thirdly, any message or session data is not protected as coming from the same site to/from user, compromised workstation or keypad. Indeed, a compromised machine may simply 'route' an attacker's data to appear to originate from the machine that commenced the session.

 

The latter problem implies, to me at least, that the keypad must become the user's communication end-point for sensitive transactions i.e. display, comms stack, security stack, tamper-resistant, effective and functional data entry mechanisms etc.

 

A simple keypad on its own isn't worth the money it costs to put them out there imho.

 

Lyal

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Smith
Sent: Wednesday, 7 December 2005 4:36 AM
To: full-disclosure@lists.grok.org.uk
Subject: RE: [Full-disclosure] Most common keystroke loggers?

I'm sure there are problems with this, but here's my idea of preventing improper authentication. At best, I think the attacker would only be able to DoS the device, or attempt replay - which would fail without the correct time-delay. I think some kind of two-part blackbox auth with time delay was what I was trying to get at :)

**   = an event
<--> = any traffic that crosses USB peripheral border, ie vulnerable data
[KP] = USB (for instance) input peripheral, with keycode entry pad
[RS] = Remote authentication site

 **[KP] is intialized upon deployment like a SecurId. It is synced with the auth server based on time, and several static algorithms.

 **[RS] is on the same time as [KP]

 **[RS] knows [KP] time-delay algorithm, and control algorithm, assoc. w/KPID.

 **

>Upon being plugged in, heres what would happen:

[KP] -- Remote auth SYN request, w/encrypted KPID sent --> [RS]

 **[RS] determines what time-delay algorithm [KP] is on by KPID. (KPID encryption is static to all components - possible point of failure.)

[KP] <--------------------- ACK sent back ---------------- [RS]

[KP] <--- Traffic averages analysis between KP and RS ---> [RS]

 **[KP] flashes green light to user

 **[KP] <-- User enters Keycode ------- [USER]

 **[KP] calculates two hashes, based on separate date/time sequence selected algorithms that are created using the current synced time, and a unique control algorithm determined during intialization.

[KP] --------- transmits first hash sequence to ---------> [RS]

 **[KP] waits x cycles based on a unique time-delay algorithm [RS] knows by KPID.

[KP] --- transmits second hash sequence to [RS] ---------> [RS]

 **[RS] uses earlier traffic analysis to determine an acceptable level of tolerance for receipt time, and determines consistency with time-delay algorithm for KPID.

 **[RS] authenticates data

[KP] <----- Close session, pass/fail errout to KP -------- [RS]

 **[KP] shuts down USB port, no further traffic until reset (several ways to do that)

[Compromised PC] <------------- Session ------------------ [RS]

What do you think?

--

___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/