lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 06 Jul 2010 21:27:52 -0400
From: Mary and Glenn Everhart <Everhart@....com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Full-Disclosure Digest, Vol 65, Issue 8

All -
Valdis remarks that there is a consensus that nothing can be done with 
an infected machine (more or less), that finding useful systems and 
protocols is viewed as infeasible.

However, I must dispute this. Please note that I did not exclude 
hardware assisted systems here, just hoped that people might think about 
what if anything can be done to produce some trustworthy results where 
devices doing communication might be infected, but where they do still 
pass bits back and forth.

Let me offer an example. Suppose we equip the person trying to establish his
identity and wishes with a simple token that bumps a counter every time 
a button
is pressed and encrypts it with a unique key and displays some of the 
result. (For simplicity
let's say person P is trying to authenticate to institution X.)

If this thing is disconnected, then it can't be infected. So let P push 
the button, tell
X the first half of the display, and X can tell P the second half. If it 
is wrong, P should
hang up immediately. Otherwise this lets X synchronize with the token 
(in case the dog
played with the button a bit or some such).

Now X can push the button again, and send P some digits from the display 
in a pattern that was previously selected. (this is not too different 
from opening a car door.) Obviously X can
tell if this was right.

At the end of the transaction, we can have the positions of the display 
labelled with
01 23 45 67 89  and maybe letters, and P can encode, say, the 
transaction amount.

Notice that X can know that the device's internal counter was in 3 
successive states, binding
these actions together.

None of this stuff will care if the transmitting system is infected. The 
digits or whatnot need to
be human transcribed, and if the whole thing is constrained to take 
place within a
limited time and logically bound as noted, it looks to me fairly hard to 
spoof.

There may be better systems (particularly for large value transactions). 
The foregoing is
an existence proof that useful systems might be devisable that may not 
depend much
if at all on inerrant software. If we could do entire transactions in 
some idempotent way,
having all these steps would not be needed perhaps. It might also be 
that additional information would be needed to constrain, say, a payee 
(consider the information on a check.)

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?

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?

Glenn Everhart

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ