Message-ID: <000901c5fc2f$73d0e6a0$6600a8c0@kpllaptop>
Date: Thu Dec  8 19:40:59 2005
From: lyal.collins at key2it.com.au (Lyal Collins)
Subject: Most common keystroke loggers?

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@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of John Smith
Sent: Wednesday, 7 December 2005 4:36 AM
To: full-disclosure@...ts.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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051209/84a17133/attachment.html

Powered by blists - more mailing lists