RE: Most common keystroke loggers?

["Lyal Collins" <lyal.collins () key2it com au>]

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: full-disclosure-bounces () lists grok org uk
[mailto:full-disclosure-bounces () lists grok org uk] 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/