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