Re: PC MSDOS hardware key proposal

[cwedgwood@cybernet.co.nz (Chris Wedgwood)]

Jyri Poldre <jp@pitsa.pld.ttu.ee> wrote:
______________________________________________________________________
Frgiv me if i am a bit off theme, but it just seemed as a good idea.
As I am going to have some off-time tonight I might forget that and on
the other hand maybe someone can use it in protecting his/her
intellectual property and  this would certainly be linked with our topic. 
The idea came to me after seeing some incredibly small piece of code
doing some unbelievable damage. Like 3 kbytes of com making hardware key
useless. I started to play with idea of having something more reasonable
for PC SW developers. For start it is not possible to use any type of key
checking, because dos is open system and allows everyone to intercept and
disable it. The lock must be a part of program itself. Also one must
concider the dataflow and power consumption, meaning you cannot have
second floating point unit in printer/serial port.You cnt put it
into slot , cause  it should be reasonably cheap. My idea for such device 
is the following:
Have the HW unit calculate the If-then-else conditions in program flow. 
it is not reasonable to do it everywhere, but just in some places(
depends on the  money/time one used to devolop product and similar
relation of expected hacking ) 
. For that purposes you could collect all results into flags and
present them to this Hw unit. It calculates the condition as boolean
function of input variables. If you want more entropy you could involve
state machine in this unit. Also some delay, what would be built into (
one cannot just send data through printer port with 32 Mbytes /sec.)
although for user it would be unnoticed , but using  brute force and  32 bits
of data this would make our friendly hacker quite old. Another alternative
is to understand the dataflow in program but from binary to get the idea...
no , this is a bad idea. so - just when it comes to ITE you present
printer port with 3-4 bytes  calling some procedure what reads flags from
global variables and returns carry - to go or to stay.
that's it. An attack might also concider just listening the device and writing
down the values but you would have to go through all checkpoints using all
possible flag values and that would take some and also involve
understanding of program dataflow.
One good point using that system is that it would possibly not always
crash- it would just for starters give you wrong answers.  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Doesn't work, atleast in some form. I have removed hardware dongle
protection that does just that by watching what the hardware does for a long
period of time (logging it) and then writing interception/emulation code.

A better idea I think is something like digital signatures. Get the hardware
to produce a digital signature or some random data. If random isn't
available then a reasonable pseudo-random algorithm would suffice provided
it was implemented carefully (well seeded). SmartCards can probably do this
with say ESIGN [see Eurocrypt '93 (or maybe 92?)]

If you do want to make a delay in your dongle (or whatever) then it should
ONLY delay for wrong responses or for patterned responses (hard to detect)
that might indicate an attempt to brute force it - like many modern UHF car
alarms and garage door openers.

Extensive control of program flow might be very difficult to program and
quite cumbersome.

Another thing - how practical is this hardware? If it is implemented on a 
micro-controller then it can be disassembled is the code inferred via other
means. PAL and GAL chips can also be read - and if the no-read bit is set
and the complexity of the device low enough (as is likely for in-expensive
devices) then you can infer whats inside these also (although usually it
not a NP-complete soln time wise....)

Chris