PhilWebb
Posts: 16
Joined: Sat Jun 24, 2017 9:29 pm

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 5:27 am

CarlRJ,.
None taken,...
I couldn't figure out how to say thanks in a reply to each person WITHOUT quoting it,...I guess I could select that and then delete the Quote.
Thanks,..

W. H. Heydt
Posts: 10589
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 5:32 am

PhilWebb wrote: I couldn't figure out how to say thanks in a reply to each person WITHOUT quoting it,...I guess I could select that and then delete the Quote.
As above, you can edit the quoted material. Just delete the parts you don't want to re-post or not reply to.

Or you could just make a general reply on the order of "Thanks for the comments from <list of names>."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23078
Joined: Sat Jul 30, 2011 7:41 pm

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 8:41 am

I just say "Thanks for all the comment everyone" or similar!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
Gavinmc42
Posts: 3438
Joined: Wed Aug 28, 2013 3:31 am

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 10:58 am

I don't know much about it but they do come with Trustzone and crypto hardware built into the ARM chips.
https://www.arm.com/products/security-on-arm/trustzone
I have no idea how it is used or how to use it, anyone got good links?

The V2 camera has a crypto chip, i2C version?
Just guessing but I am assuming this is read by the VC4, probably by code in the start_x.elf.
This in effect turns the V2 camera into a dongle.

The i2c2 port is on the HDMI port, you could even make a i2c dongle with a HDMI plug.

Probably the USB dongle would be the easiest as the dongle suppliers would provide software libraries?

If you are making PCB hats with your product, a HAT with a i2c crypto chip.
http://www.microchip.com/design-centers ... n/overview
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7008
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 12:16 pm

Gavinmc42 wrote:I don't know much about it but they do come with Trustzone and crypto hardware built into the ARM chips.
https://www.arm.com/products/security-on-arm/trustzone
I have no idea how it is used or how to use it, anyone got good links?
TrustZone and Secure boot is an option, but then you need to secure the entire boot sequence. Gordon did work on something related to that for the firmware boot, but it seriously limited what you could do over updating the system.
Gavinmc42 wrote:The V2 camera has a crypto chip, i2C version?
Just guessing but I am assuming this is read by the VC4, probably by code in the start_x.elf.
This in effect turns the V2 camera into a dongle.
Correct, but that then means that anyone with a V2 camera could use the software - it's not something that is in the OPs control.
Using a similar device would be a suitable hardware mechanism, but still vulnerable to reverse engineering the software and replacing the function return with something that always passes. (start_x.elf is vulnerable too but seeing as it isn't ARM code there aren't the tools around to make life easy).
Gavinmc42 wrote:The i2c2 port is on the HDMI port, you could even make a i2c dongle with a HDMI plug.
As long as you don't interfere with the EDID then you could in theory, however you'd have the normal issues of no arbitration between the GPU and ARM for the I2C block.
Gavinmc42 wrote:Probably the USB dongle would be the easiest as the dongle suppliers would provide software libraries?
Libraries are not necessarily available for ARM. They aren't cheap either.
Gavinmc42 wrote:If you are making PCB hats with your product, a HAT with a i2c crypto chip.
http://www.microchip.com/design-centers ... n/overview
Again you need to think carefully about how you use them for security, and make sure you don't compromise it within your implementation. Using it to encrypt some communication back to a server would be great as the other half then is not shipped with your device.

As previously said, it all comes down to what you can secure within your app, and what the cost implications would be for those who really want to hack it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Gavinmc42
Posts: 3438
Joined: Wed Aug 28, 2013 3:31 am

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 12:58 pm

Ah, back in the good old days we used battery backed ram, opening the case disconnected the ram.

Something we have been thinking about with Ultibo is net updating.
The source is compiled to a kernel.bin specific to the Pi's serial number.
But is the net safe? This could also be RE by comparing multiple kernel.bins.
Have encrypted code that gets unencrypted into ram on boot.
Encrypted zip file?

It is now possible to write your own start.elf, as long as you don't need much of the normal stuff in that.
If your app needs graphics, probably going to need the usual start.elf.
Could also write your own bootloader too now. There are simple examples out there.

Secure MicroSD cards? If viruses can be put in the ARM chip in SD cards why not security?
Boot from USBstick? Make your own USB sticks?
They are easer to hack than microsd, just need flash chip reader :lol:

Pi's are bound to end up in IoT devices. Probably already are, RPF not allowed to tell.
Securing IoT? Big big kettle of fish.

I would listen to what 6by9 and jamesh have said, subtle hints?
They do have more insight into the Pi's than the rest of us and have probably seen more Pi's used embedded than anyone else.

Anything worth hacking will be hacked. Even things not worth hacking get hacked just for fun.
A couple of local boys here cracked credit cards chips decades ago just to prove it could be done.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

PhilWebb
Posts: 16
Joined: Sat Jun 24, 2017 9:29 pm

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 1:45 pm

This is what we have worked out so far. Anyone have any input regarding if it would be adequate? Do you see any faults in these ideas?

Specs on SD card protection for RPi

0. Have points 1 and 2 to run only once and only the first time.
1. Get the MAC and serial of the Pi and have them written to a variable inside the program.
2. Have the program recompile itself with the previously acquired MAC and serial strings added inside of itself.
3. For subsequent power cycles have the Pi's MAC and serial read and compare to the previously stored MAC and serial.
4. If there is any inconsistency between the stored MAC and serial and the current Pi's MAC and serial, prevent the rest
of the code from running.

Now, to further increase the protection and ensure the program hasn't been changed by someone, you can run an md5 check
for that, you would need to have an md5 generated after point 2, store that md5 hash somewhere else, and have the program do this

-> check for its own md5 hash
-> compare its md5 hash with the stored md5 hash
-> if the md5 hashes don't correspond, prevent the code from running.
-> if the previously stored md5 hash is deleted, and the program has nothing to compare it to, also prevent the code from running.

Key points are: getting the unique identifiers of the pi-> have the program modify itself accordingly-> have its md5 hash generated
-> store md5 in separate file-> have the program check for correct MAC, serial, and md5, if any is incorrect, do not run, or, be deleted.

Also there may be a need to use encryption of the SD card,.. Need to check to see if this would slow down the RPi beyond any acceptable limit.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7008
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 2:53 pm

The ethernet MAC address is b8:27:eb and then the last 6 hex digits of the serial number.
The Wifi MAC address on the Pi0W/Pi3 is likewise based on the serial number with an extra munge.
Using the serial number and MAC address therefore adds very little to the security.

As discussed before, with a little kernel hackery you can spoof the serial number.

SD card encryption is a funny one as the decryption key has to be stored somewhere. There is no non-volatile storage on the Pi, so that pushes it to either be manually entered, or stored on that same SD card. It may stop you interpreting the card data on a different machine, but won't stop you copying the whole card.

You previously said you were worried about your dealers copying the system without reporting the sale. In that case if they copied the card before the first setup run the they've bypassed your whole scheme.

Doing security properly is really hard.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

W. H. Heydt
Posts: 10589
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 3:31 pm

PhilWebb wrote:This is what we have worked out so far. Anyone have any input regarding if it would be adequate? Do you see any faults in these ideas?

Specs on SD card protection for RPi

0. Have points 1 and 2 to run only once and only the first time.
1. Get the MAC and serial of the Pi and have them written to a variable inside the program.
2. Have the program recompile itself with the previously acquired MAC and serial strings added inside of itself.
Just to play "black hat" fora moment... Step -1 Remove and back up SD card image.

itimpi
Posts: 1084
Joined: Sun Sep 25, 2011 11:44 am
Location: Potters Bar, United Kingdom
Contact: Website

Re: Protecting Proprietary software from being copied.

Tue Jun 27, 2017 3:53 pm

As many have said one has to work out the trade-off between effort and cost for security.

Security that binds the software to the Pi serial number is probably a relatively simple thing to do and is pragmatic way to provide simple security. This after all is the protection applied to the additional codecs that can be purchase for the Pi. Agreed that this can be reverse engineered but from what I can gather from the requirements stated this may be sufficient to make it not worthwhile for those who might want to be dishonest. One possible downside to this approach is that if the pi hardware failed the SD card cannot be simply moved to an alternative, Whether this is really an issue in the intended use I have np idea.

Zebu
Posts: 29
Joined: Tue Aug 11, 2015 1:57 am
Location: Australia

Re: Protecting Proprietary software from being copied.

Wed Jun 28, 2017 3:37 am

some of the software we use at my work is protected by this

https://sentinel.gemalto.com/software-m ... l-hasp-hl/

they claim linux support but i don't know if that extends to arm.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7008
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Protecting Proprietary software from being copied.

Wed Jun 28, 2017 9:23 am

Zebu wrote:some of the software we use at my work is protected by this

https://sentinel.gemalto.com/software-m ... l-hasp-hl/

they claim linux support but i don't know if that extends to arm.
Looks like it does to some extent - https://sentinel.gemalto.com/software-m ... -ldk/#tab1
Sentinel LDK Run-time Environment and Vendor Tools:

OpenSUSE 12.3, 13.2 (x86 and x86_64)
Red Hat EL 6.7, 7.2 (x86 and x86_64)
Ubuntu Desktop and Server 16.04 (x86 and x86_64)
Ubuntu Server 14.04 (x86 and x86_64)
Debian 8.1 (x86 and x86_64)
CentOS 7.1, 7.2 (x86 and x86_64)
Linux ARM(armel and armhf) hardware/boards validated: BeagleBoard-xM Rev C; BeagleBone Black; Raspberry Pi-2; PandaBoard ES Rev B3; NI cRIO-9068
I've also used those in a past life from when they were under the Aladdin brand. They weren't the cheapest of items - my recollection from around 2005 is they were about £50 a shot in small quantities, and you needed the dev kit first which was several hundred.
IIRC their SDK (at least under Windows) also offers a chance to encrypt the executable, and the dongle gives you the decryption key. In theory under Linux if you had root access you could then read the decrypted executable from memory, but it's increased the complexity of reverse engineering again.

It all comes down to how much effort and money you want to expend on your security development, and per product sold.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Gavinmc42
Posts: 3438
Joined: Wed Aug 28, 2013 3:31 am

Re: Protecting Proprietary software from being copied.

Wed Jun 28, 2017 1:32 pm

I guess if you are using Linux then using Buildroot to make a kernel with just what you need in it.
Remove all the external access stuff like serial console, ssh etc

Can Buildroot handle encrypted file systems?

PiCore boots into and runs from ram, like Ultibo once running you can pull the sdcard out.
If you had a UPS then the app could erase the SD card.
Some of my IoT piCore based gadgets run for months, they only reboot on power cuts.
Last time I checked, years ago,173 days uptime was not uncommon.

Dongle decryption to ram and run from ram?
The last time I used a dongle it was a parallel port one, no idea what is state of the art these days.
Google time?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

PhilWebb
Posts: 16
Joined: Sat Jun 24, 2017 9:29 pm

Re: Protecting Proprietary software from being copied.

Wed Jun 28, 2017 6:57 pm

Thanks for the most recent comments,...Also for any future comments on this. I can see where ones imagination can let this idea run rampant, I'm talking about me.
The idea crossed my mind to allow the device to work temporarily on another PI long enough to let the program send in a report as to the serial number that was on the SD card so I would know who has made a copy of the SD card. Once the program was able to send a report to me then it would shut itself down and would allow a screen to explain that due to mismatched SD card/RPI etc this program has been halted.

Then I decided that I could be thinking about this a little too much.
Phil

i486
Posts: 172
Joined: Sun Aug 28, 2016 3:41 pm
Location: BG

Re: Protecting Proprietary software from being copied.

Wed Jun 28, 2017 9:03 pm

The question for software protection is very old and discussed million times without ultimate solution. Using hardware dongle is one of the "strong" methods, but there are at least 2 problems:
1) The price of dongle is not small and for cheap software it is useless. E.g. if you want to sell software for 50$ and the price of dongle is 30$...
2) You have to develop your own unique dongle. If you use standard dongle developed by other, there is high probability to exist "crack" for it.

The only safe method for protection is to use MCU and lock it for external reading. But the price for development of embedded software will be 10-50 times higher than the price for normal PC software - and it will run slower plus other limitations for RAM/storage/etc.

Probably the DRM features of SD card can be used for some kind of protection and control. Unfortunately, their documentation is limited for SD.org members with corresponding paid membership. To read the serial number of SD card is one simple method but it is even simplier to issue license keys based on Pi/ethernet(bluetooth) MAC address.

PhilWebb
Posts: 16
Joined: Sat Jun 24, 2017 9:29 pm

Re: Protecting Proprietary software from being copied.

Wed Jun 28, 2017 10:15 pm

W. H. Heydt wrote:
PhilWebb wrote:This is what we have worked out so far. Anyone have any input regarding if it would be adequate? Do you see any faults in these ideas?

Specs on SD card protection for RPi

0. Have points 1 and 2 to run only once and only the first time.
1. Get the MAC and serial of the Pi and have them written to a variable inside the program.
2. Have the program recompile itself with the previously acquired MAC and serial strings added inside of itself.
Just to play "black hat" fora moment... Step -1 Remove and back up SD card image.
If I understand you correctly, you're saying that the end user could pull the SD card and make a backup,. many back ups before the initial run?
We would be the first ones to run the device ourselves so that this option would not be available to the end user.
If you meant something else please let me know as I'm interested in understanding your meaning.
Thanks,
Phil

BMS Doug
Posts: 3824
Joined: Thu Mar 27, 2014 2:42 pm
Location: London, UK

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 7:36 am

Much like purchasing additional codecs for an individual Pi, you should indeed be able to generate a decryption key based on the Pi's individual serial number (I believe the MAC address is derived from the serial number).

You could then issue any customer a new decryption key by email upon request (once you approve the request).

Just keep close control over the decryption key generator (but not so close that you lose the only copy).
Doug.
Building Management Systems Engineer.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7008
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 9:09 am

BMS Doug wrote:Much like purchasing additional codecs for an individual Pi, you should indeed be able to generate a decryption key based on the Pi's individual serial number (I believe the MAC address is derived from the serial number).

You could then issue any customer a new decryption key by email upon request (once you approve the request).

Just keep close control over the decryption key generator (but not so close that you lose the only copy).
Any IPC call to the GPU goes through the kernel. The kernel is open source, so if you have the access to the SD card then you can replace the kernel with a version that intercepts just those IPC calls and returns an answer of your choosing. Use strace and it will probably even tell you exactly which kernel calls are being used when doing the security check during startup.
So then you have to ask how to secure the kernel to prevent replacement with a random version, however you probably want the user to be able to update the kernel to handle security updates. Have you got that bigger can to put the worms in?

The codec check is secure enough as the GPU is the one reading the OTP directly, so the return result can't easily be subverted.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
Gavinmc42
Posts: 3438
Joined: Wed Aug 28, 2013 3:31 am

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 11:45 am

The codec check is secure enough as the GPU is the one reading the OTP directly, so the return result can't easily be subverted.
How much OTP is left and unused?
Enough for a longer key than the serial number?

Letting imagination run wild is where ideas become flying ducks, forums are where they are shot down :lol:
With just the few posters on this one post we have hundreds of years of real world experience.

Pi's in IoT will need solutions, not just for protecting the code.
Personally I will be avoiding Linux, made that decision over a year ago.
Still only have something that is about as secure as Win98, next year maybe WinXP?

Have the big boys a solution? all those RTOS providers.
Embedded CM users might come up with something, but they are the ones most likely to stay silent.

What ever your software does, protecting it will last as long as it takes for someone writes similar software that does the same thing. Without having hardware to go on the Pi along with your software, the serial number is the easiest place to start.
If you are selling hardware as well you have more options.

Anyway you have made me think about this more.
Conclusion - I have no idea and need to learn more, starting with - how does trustzone work?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

i486
Posts: 172
Joined: Sun Aug 28, 2016 3:41 pm
Location: BG

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 12:12 pm

Small executable runs from SD card. Loads another encrypted executable in memory. Decryption is made with S/N of SD card and then the main executable is started. If you clone the SD card, the soft will not run because S/N of the second card is different.

audigex
Posts: 17
Joined: Wed Sep 19, 2012 1:37 pm

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 12:52 pm

The best real answer I have to "Protecting my software" is "Make it into a web service"

You have the overhead of running the server (and as with the authentication mentioned above, you'll have annoyed customers if your servers go down) - but you retain much more control over your service, since you're only providing user accounts rather than source code

It isn't suitable to all applications, but where it is then it's generally the best option.

W. H. Heydt
Posts: 10589
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 4:04 pm

PhilWebb wrote:
W. H. Heydt wrote:
PhilWebb wrote:This is what we have worked out so far. Anyone have any input regarding if it would be adequate? Do you see any faults in these ideas?

Specs on SD card protection for RPi

0. Have points 1 and 2 to run only once and only the first time.
1. Get the MAC and serial of the Pi and have them written to a variable inside the program.
2. Have the program recompile itself with the previously acquired MAC and serial strings added inside of itself.
Just to play "black hat" fora moment... Step -1 Remove and back up SD card image.
If I understand you correctly, you're saying that the end user could pull the SD card and make a backup,. many back ups before the initial run?
We would be the first ones to run the device ourselves so that this option would not be available to the end user.
If you meant something else please let me know as I'm interested in understanding your meaning.
Thanks,
Phil
I had not understood that you were going to do the initial run yourself. You scheme implies that the purchaser has to pay for, not only the software, but a specific Pi that it runs on, this adding an absolute minimum of $35--and probably more--to the total package.

Many good comments have been made. Part of the overall problem is that, in general, honest people hate DRM because they quite legitimately think they're being penalized by vendors for the actions of the dishonest. The dishonest only see DRM are a minor bump in the road on the way to what they want to do. As a result, you are on the horns of a dilemma and you will have to find a solution that you are willing to live with.

W. H. Heydt
Posts: 10589
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Protecting Proprietary software from being copied.

Thu Jun 29, 2017 4:13 pm

Gavinmc42 wrote: How much OTP is left and unused?
Enough for a longer key than the serial number?

Letting imagination run wild is where ideas become flying ducks, forums are where they are shot down :lol:
With just the few posters on this one post we have hundreds of years of real world experience.
Let me grab a shotgun.... Using OTP bits is a really, really (and I mean REALLY) BAD idea. Even if there are enough bits, you never know when or how many will be allocated to some new feature, or existing uses will be moved around in a future iteration or design.
Pi's in IoT will need solutions, not just for protecting the code.
Personally I will be avoiding Linux, made that decision over a year ago.
Still only have something that is about as secure as Win98, next year maybe WinXP?
I have this vague recollection from years back that there is a secure version of Linux. Secure enough to permit holding highly classified information on such systems. (And, if it comes to that, AT&T developed a real time unix kernel for use in central office switches, so the whole RTOS issue has also been solved, for unix if not Linux.)

Return to “General discussion”