Hi, I’m using the G120 with the GHI Libraries 4.3.7.10
I can’t find the property or function GHIElectronics.NETMF.Hardware.Configuration.TinyBooter.DisableApplicationAccess
I guess the namespace and/or property name must be different but I can’t find it…
Anyone knows the location?
@ Mogollon - Unfortunately due to changes in NETMF between 4.1 and 4.3 we had to remove the feature because it was possible to circumvent the protection.
Ok, so right know the code on any device could be downloaded using the MFDeploy?
Is there any way to protect the code in the device?
@ Mogollon - MFDeploy can read the program from the device. Your best bet is to physically protect the device.
If you are trying to protect an intellectual asset buried in the code, then there isn’t too much you can do (and physical protection of the device only works if the effort required to circumvent it is greater than the value of the asset).
If you are building a connected device (one which relies on an online component), you can always embed a cryptographic keys in the app AND keep some part of the device’s overall value in the cloud so that copying the firmware doesn’t result in a fully workable standalone solution. That’s only a viable solution in a limited set of applications where the online component is an essential adjunct to the device firmware.
@ mcalsyn - So once you extract the keys from the device with MFDeploy you’ll have it all. Therefore, every program of any value is very easily stolen.
Not exactly - I didn’t go into complete detail there. You are right that JUST a crypto key is not enough. You have to combine 1) public key; 2) unique device identity; 3) server-based challenges and 4) significant off-device value
If you create a device that contains a public key, and a unique identity (preferably in hardware - for instance, using one of the one-wire devices) and your online service issues cryptographic challenges, then duplicating the firmware won’t gain you access to the online service with a ‘fake’ device. Someone can duplicate the device, but it doesn’t earn them much. Much of the value is off-device, and you can disable on-device value in the absence of validated server challenges.
This really only works with a specific type of application. That is, applications where a key part of the value proposition (say, the analytics suite or a companion mobile app) is cloud-based. You can extend this model to devices that don’t support direct internet access by building a trust chain that includes intermediate controllers.
The key trick here is to destroy the value of duplicating the least-well-defended components.
@ mcalsyn - NETMF devices don’t have a secure boot. The upcoming BBB module will. Any unique device id can be easily read by an attacker.
Ah, I see what you’re trying to say. Do the valuable work in the cloud not on the device.
Yes, you could synthesize the device id, but server side checking could detect that duplication heuristically. Secure boot would be better, but server side heuristics are an adequate replacement. Again, this isn’t a one-size fits all solution - it’s for a particular class of apps.