How to restrict access from Prop to Mac

T Chap

I have an app on the Mac and a Prop device that connects via USB. I want to prevent someone reverse engineering and adapting their own device to avoid buying it but don't want to get into adding licensing to the app. On launching the app it connects to the Prop via the silabs cp2110. It would be easy to send some pseudo random info like time date, mouse position, pixel color under the mouse etc to the Prop for it to do some math and reply with some response based on a formula. I am looking for ideas on how this might be done. Any thoughts?

ke4pjw

Have you looked at FTDIChip-ID?

http://www.ftdichip.com/Products/ICs/FT232R.htm

jmg

T Chap wrote: »

.. I am looking for ideas on how this might be done. Any thoughts?

Almost any query-response massage will give some protection.
You could include a version message, which is useful anyway, and then use the firmware version number to scramble the scrambler...
Of course someone can reverse engineer the PC side and skip over this step, so you might want to include in the Prop side a verify-passed flag.
That leaves someone could reverse engineering both ends, and if you wanted still more protection there, use a small 8b MCU (EFM8,N76E003,...) as a key ?

ke4pjw

Looking at the CP2110, you might be able to program a serial number into the "Serial String" field that can be validated by your software. Looks like you can program up to 30 ASCII characters.

KeithE

jmg wrote: »

T Chap wrote: »

.. I am looking for ideas on how this might be done. Any thoughts?

Almost any query-response massage will give some protection.
You could include a version message, which is useful anyway, and then use the firmware version number to scramble the scrambler...
Of course someone can reverse engineer the PC side and skip over this step, so you might want to include in the Prop side a verify-passed flag.
That leaves someone could reverse engineering both ends, and if you wanted still more protection there, use a small 8b MCU (EFM8,N76E003,...) as a key ?

Along these lines you could browse through the Atmel documents for their CryptoAuthentication products. Here's a high-level one:

http://www.atmel.com/Images/Atmel-8794-CryptoAuth-ATSHA204-Product-Uses-Application-Note.pdf

Then start here if that is interesting:

http://www.atmel.com/products/security-ics/cryptoauthentication/default.aspx

T Chap

Thanks for the suggestions. I forgot about being able to burn some info into the rom. I do need to study these crypto devices to.

rbehm

Some additional idea:
You are afraid somebody might copy you device. This is probably always possible, it is just a question of how much effort somebody puts into this.
To make it more complicated for the copycat, I once implemented some kind of protection, that made the device misbehave randomly. You could put this into the program running on the Mac.
Any message showing the detection of the illegal copy will make it easy for the copier to test , but random errors or crashes will make live more complicated for him.

KeithE

> but random errors or crashes will make live more complicated for him.

But really irritating for anyone who is a legitimate user but is having problems for whatever reason. If FlexLM did this for EDA software, it could cost companies millions of dollars. Anyways something to keep in mind.

rbehm

KeithE wrote: »

> but random errors or crashes will make live more complicated for him.

But really irritating for anyone who is a legitimate user but is having problems for whatever reason. If FlexLM did this for EDA software, it could cost companies millions of dollars. Anyways something to keep in mind.

That's one reason people dislike copy protection. It can make life harder for legitimate users.

T Chap

That's why I don't want to add licensing stuff it can be a pain. I need a speed bump to put a little hurdle if someone wants to use the app and not the physical counterpart. The app was 1000's of man hours and lots of money for programmers. You don't want to just say "here you go" use my app for free if you can sniff out the USB transactions.

Mark_T

How can you stop someone reading the EEPROM on the Prop device and cloning it? You would need to add a
tamperproof device for proving identity I think.

ke4pjw

Mark_T wrote: »

How can you stop someone reading the EEPROM on the Prop device and cloning it? You would need to add a
tamperproof device for proving identity I think.

You don't/can't. You make sure the software on the computer ensures that a legitimate device is plugged in. That can be done with the security dongle features provided by various USB UART chips.

T Chap

CP2110: The on-chip, one-time programmable ROM provides the option to customize the USB Vendor ID, Product ID, Manufacturer Product String, Product Description String, Power Descriptor, Device Release Number, Device Serial Number, and GPIO configuration as desired for OEM applications

There are vendor id and product id already built in the device from the factory. My existing code looks for the specific vendor and product id on connection, this is the code below that does the checking. I believe it is fairly easy to write the ROM with my own info so I will explore that and then the app will look for my unique information. I believe you are not allowed to just make up vendor ID's per USB spec but I'll have to study this some more, maybe leave the generic ID's alone and modify the manufacturers product string, device serial etc. I am not sure really how possible it is to sniff these on USB connection, else someone could just program a CP2110 with the same info. However, I am not trying to go too crazy on this, just need to make some slight effort.

// Check if the CP2110 is present by filtering for the vendorID and productID
dim n as integer
mLastError = HID2UART.GetNumDevices(n, mVendorID, mProductID)
if mLastError <> HID2UART.SUCCESS then
  // not device found.
  Error
  return false
end if

// The device has been found
mIsPresent = true

// Open the device
mLastError = HID2UART.Open(mDevice, 0, mVendorID, mProductID)
if mLastError <> HID2UART.SUCCESS then
  // couldn't open the device.
  Error
  return false
end if

T Chap

...customizing the VID/PID combination is stronglyrecommended. A unique VID/PID will prevent
the device from being recognized by any other manufacturer’s
software application. A vendor ID can be obtained from www.usb.org or Silicon Labs can provide
a free PID for the OEM product that can be used with the Silicon Labs VID. All CP2110 devi
ces are pre-programmed with a uniqueserial number. It is important to have a unique serial if it is possible for multiple CP2110-based devices to be connected to the same PC.

T Chap

Just found this tool on their site to burn the ROM. Pretty simple stuff.

KeithE

> I am not sure really how possible it is to sniff these on USB connection, else someone could just program a CP2110 with the same info.

I'm pretty sure that this is trivial to do. They don't seem to tout any security features.

kwinn

Having the app download the program to the propeller chip ram instead of the eeprom would add enough complexity to discourage attempts to use it for other hardware.

T Chap

Kwinn I thought about that exact thing, and one benefit is that the firmware is always current with the app.

jmg

kwinn wrote: »

Having the app download the program to the propeller chip ram instead of the eeprom would add enough complexity to discourage attempts to use it for other hardware.

T Chap wrote: »

Kwinn I thought about that exact thing, and one benefit is that the firmware is always current with the app.

A variant on this would be to flip the i2c pins, so standard loader does not work, or use SPI memory, and thus system appears to be EEPROM less, but you can store serial ID in the 'invisible' NV memory, and so force a complete hardware clone - generic off the shelf Prop hardware will not work.