Post by thread:[EE]: Need to implement dongle functionality over

I need to make a circuit that has software protection dongle functionality. I though of just putting the serial number in a EEPROM, but the trouble is that the device is RS232, and it would be dead simple for a cracker to mimic the RS232 conversation. I figure that there also needs to be some kind of encryption thing going on. Can this be done practically in a low-mid range (4K) PIC? Is there some example firmware available? Is there a chip out there that I could just sit on my board that will do the encryption and serial number storage? The other end of the encryption is the software that is being protected, so I think that excludes the KeyLoq devices. The system needs to be as cheap as possible and still offer some fair level of protection. Thanks in advance for any advice or assistance you can offer. -Brent -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Brent Crosby wrote: > I need to make a circuit that has software protection dongle functionality. > I though of just putting the serial number in a EEPROM, but the trouble is > that the device is RS232, and it would be dead simple for a cracker to > mimic the RS232 conversation. Not if you use a challenge/response that uses the serial number as part of the encryption key. The key is that EVERY challenge is unique, with a unique response. > I figure that there also needs to be some kind of encryption thing going on. Of course. > Can this be done practically in a low-mid range (4K) PIC? Is there some Sure. A 12Cxxx part could do it. > example firmware available? Somewhere out there. > Is there a chip out there that I could just sit on my board that will do > the encryption and serial number storage? The other end of the You could program a PLD to do a simple brute force PRN encryption. With 128 bits it could take a while for them to figure out the internal connections. Since you issue different challenges each time, you have 2^128 -1 possible challenges with a corresponding (not necessarily unique) response. Essentially the challenge contains a key to load into the shift register, the taps to use, and the number of shifts to invoke. You assign the bits randomly to the PLD. >encryption > is the software that is being protected, so I think that excludes the > KeyLoq devices. Why? It does the above. Encrypt your executable and only decrypt at execute time using your required response. It's easy enough to set up the executable to detect tracing/debugging hooks (Ints hooked, timing that's wrong, CRCs on the code to detect breakpoints). If you make it hard enough (relative to payoff), they go elsewhere. If the 'hack' is valuable enough, it WILL happen. > The system needs to be as cheap as possible and still offer some fair level > of protection. Cheap/effective. You can have only ONE <G>. Effective is a failed response causing irreversible erasure. All systems are compromisable. Just look at DSS satellite services. Every time Huges comes out with a new 'better' card, the hackers break it. Hell, even Modex (the 'unbreakable' money card) has been compromised. Talk about 'printing your own money'... What is the value of your product? What do you stand to loose if it's stolen? Then figure out how much you're willing to spend to -really- protect it. Lots of options... Robert -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> Not if you use a challenge/response that uses the serial number as > part of the encryption key. The key is that EVERY challenge is unique, > with a unique response. The software has to have "unencrypted" code that will make the challenge and test to see if the response is correct. How could you keep a cracker from simply mimicing the KEELOQ device? I better idea may be to make the dongle a necessary part of the software. If you are writing your software in C++, for example, put a routine that isn't too processor intensive ONTO the PIC. Thus, the PIC would be contributing to the actual execution of the program. This makes your security extremely dynamic, a cracker would be really fried to do this because he would have to reverse engineer your source code. Think about it, no matter what a wannabe cracker tries, the software is essentially "incomplete" without with a functioning dongle! (I shock myself with these ideas sometimes....) Obviously a 12Cxxx won't do it. Unless you're REALLY creative. I'd use a 16F8xx part or anything with extended amounts of programming space. If you would like more details on how to do this just contact me, I don't require money. Just a challenge and a little time. Anthony Clay spam_OUTzarthragTakeThisOuTintcon.net -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 02:46 PM 7/6/00 -0600, you wrote: > >> The system needs to be as cheap as possible and still offer some fair level >> of protection. > >Cheap/effective. You can have only ONE <G>. You do have to keep in mind that no matter how great an encryption algorithm you use in the dongle, a hacker can always bypass the checks in the PC program so it doesn't even look for the dongle! Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Spehro Pefhany --"it's the network..." "The Journey is the reward" .....speffKILLspam@spam@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 04:11 PM 7/6/00 -0700, you wrote: >I better idea may be to make the dongle a necessary part of the software. >If you are writing your software in C++, for example, put a routine that >isn't too processor intensive ONTO the PIC. Good idea, preferably the most tricky algorithm in your system, so as to make it difficult to reverse engineer. Then you'd have to be up against a multi-disciplinary adversary, a lot less likely. Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Spehro Pefhany --"it's the network..." "The Journey is the reward" speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

To reduce this to the absurd... If you could find a real and necessary high level function in the main program that calls different series of sub functions based on values that change with over time, you could tokenize the addresses of the sub functions, then translate the calling function into a token list which is placed in the PIC and dispatched over the RS232 link with each subfunction result returned to the PIC so that it can decide which way to branch in the token list. I.e. make the PC a very big interpreter for a program that is actually running in the PIC. The only point in doing it that way is that if the processing time of the subfunctions is substantial, then the overhead introduced by waiting for the PIC to "call" the next function will be less of an impact on the execution speed of the application while still resulting in a non-trivial complexity of the data flowing over the RS232 wire and the state of the processor in the PC. The routine in the PIC doesn't have to be too complex then, just a series of compares, branch, and change token sequences. --- James Newton .....jamesnewtonKILLspam.....geocities.com 1-619-652-0593 {Original Message removed}

> I figure that there also needs to be some kind of encryption thing going on. > > Can this be done practically in a low-mid range (4K) PIC? Is there some > example firmware available? Simply encrypting the serial number and spitting it over the serial line wouldn't work. The snooper would only have to re-transmit the encrypted serial number to make it work. (maybe this is obvious -- but I wanted to make sure we were on the same page) Two schemes come to mind: 1. Computer sends a message to dongle (say 64 bits) -- Dongle encrypts message with secret key and sends encrypted message back to computer. Computer verifies that the ciphertext is indeed the expected plaintext encrypted with the secret key. 2. Computer generates a public / private key pair, sends the public key to the dongle, the dongle encrypts message with public key, and then computer verifies decrypts with private key, and verifies that the plaintext is a valid serial number. In both cases a key part is that the expected return message (from dongle to computer) is not constant. This way a simple snoop & repeat attack won't work. The problem #1 is that if the private key is compromised, all of your dongles are compromised. With #2 if someone figures out the plaintext, they can implement a dongle that does exactly what yours does. Perhaps a combination of the two schemes. Secret key + dynamic public key, two pass encryption..you get the picture. I haven't actually done this, but I would expect that you would be able to accomplish this with a modest pic. -Steve -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Don't forget to hook all the extra unused lines from the port to the dongle and toggle them randomly (being careful not to impede data flow through to the next device) Try to make really strange signals and connections, too. That always annoys people who reverse engineer the hardware dongles. ;-) -Adam Brent Crosby wrote: {Quote hidden}> > I need to make a circuit that has software protection dongle functionality. > I though of just putting the serial number in a EEPROM, but the trouble is > that the device is RS232, and it would be dead simple for a cracker to > mimic the RS232 conversation. > > I figure that there also needs to be some kind of encryption thing going on. > > Can this be done practically in a low-mid range (4K) PIC? Is there some > example firmware available? > > Is there a chip out there that I could just sit on my board that will do > the encryption and serial number storage? The other end of the encryption > is the software that is being protected, so I think that excludes the > KeyLoq devices. > > The system needs to be as cheap as possible and still offer some fair level > of protection. > > Thanks in advance for any advice or assistance you can offer. > > -Brent > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Bob Blick wrote: >Why bother? DMCA makes any bypass of your copyright illegal, so any method >you use is good enough, even if it's a 47K resistor on the game port(or >equivalent in simplicity for rs232 port, say a diode and a resistor on >the control lines). I guess the long arm of the DMCA will take a while to reach one-diskette countries. Me apparently being in one from what I gather on the market and in the media. Peter -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Fri, 7 Jul 2000, Peter L. Peres wrote: > I guess the long arm of the DMCA will take a while to reach one-diskette > countries. Me apparently being in one from what I gather on the market and > in the media. In the same train of thought, the lost sales will also be minimal. In the US, DMCA has had a dramatic effect. How about changing the topic to "Do you hate dongles?" I do. -Bob -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Spehro Pefhany wrote: >You do have to keep in mind that no matter how great an encryption >algorithm you use in the dongle, a hacker can always bypass the checks in >the PC program so it doesn't even look for the dongle! Unless, like in all commonly used dongles nowadays (or so I'm told), the dongle is used to un-hash the function addresses on an as-you-need basis. The host has a small cache of these. The issue is complex. I understand that this is what commercial dongle/license programs do for you. Peter -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

One way to do what you want is: - pick a hash algorythm (md5 will work) - make a PIC dongle with a key in EEPROM that implements the following algorythm: - when challenged by host, receive data packet (a hash seed) - hash data packet with key using algorythm - send hashed packet back Assuming that the host knows the key (or the valid keys) it will perform the same computation. If the returned data is different from the computed data, it's fraud. The hash seed to be sent out can be something like the time of day multiplied by the amount of free hard disk space modulo 64 bits times a random number. You get it. To avoid storing large numbers of keys in the application, you can pick an incomplete sequence PRNG or some other function like that to generate the raw valid keys on, say, 0-16384 interval and then bit-permutate them into the larger (64 bit) real keys. For normal mortals (like me) who have small series production, this can be a table of only 64k in size in the host, to seed, to hash, and compare the returned hash against. This is enough for 8192 valid keys out of 2^64. If you use a 1200 Baud link then it would take a cracker more than 4 years to try by brute force, with a probability of 1/1000000, on 2^64 hashed keys. Of course one of the first trials could yield a valid key ;-) This scheme is not foolproof and if someone reverse engineers the host source then he will have many keys. A slightly better way uses a license file, a computed function pointer table, the serial number of your hard disk, and NO pic or dongle, although you can still wedge one in if you really want to ;-) Users hate dongles (me too). I can live with license files. hope this helps, Peter -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.