Re: PC MSDOS hardware key proposal

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

> Extensive control of program flow might be very difficult to program and
> quite cumbersome.
exactly. But to my mind this is the big point. (Although i am very often
wrong) It seems to me, that the problem lies in the function of HW key in
program. If it is used in "check the existance" way then you can easily
remove the checks from binary code. And it does not matter what is the
essence of checking- You will always have 
CMP KNOWN_DATA, HW_KEY RESPONSE. 
that makes me sad. If you are planning to use RND generator then here is
the weak point- it only takes some time to locate it (even physical one )
and in case of everybody-reads-everything-and-writes-too situation you
could feed this program what uses HW signatures with known data. And the
program will never know the difference.    
> 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

OH, I have not given it a really good thought. ucontroller seems to work
fine - since for obvious reasons you cannot put there 2^32 bits of
ROM. I have used MC68HC705 with printer ports.  But of cource you must
concider the time it takes and breaks.( And maybe it is better to use some
Unix system to begin with where root must be the 'responsible one'  with
license servers.)    

JP.

Jyri Poldre writes
> It seems to me, that the problem lies in the function of HW key in
> program. If it is used in "check the existance" way then you can easily
> remove the checks from binary code. And it does not matter what is the
> essence of checking- You will always have 
> CMP KNOWN_DATA, HW_KEY RESPONSE. 

"Check the existence" is only used by amateurs.

A typical gimmick, one that I wrote, is get information from the
hardware, mangle it, put it on the stack, and execute it.   And
there are loads of tricks like that that can seriously obfuscate 
code.

No software protection scheme is unbreakable, but it is easy
to make a protection scheme that is not worth breaking. 

Of course the inconvenience to the user may well be such that
it is not worth protecting, either.



-- 
 ---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we        James A. Donald
are.  True law derives from this right, not from
the arbitrary power of the omnipotent state.            jamesd@acm.org