ertank
Posts: 48
Joined: Sat Feb 18, 2017 4:44 pm

Secure app running on Pi

Tue Dec 10, 2019 9:35 am

Hello,

We have a compiled application, GUI, running on Pi. We will be putting that application on an SDCARD/Flash Disk/mSATA and giving away with Pi itself.

We would like to protect that application to be copy/paste to another place for reverse engineering, etc.

We thought of;
1- Use a strong password for user pi like 16 characters with everything mixed.
2- Use LUKS and put out application on an encrypt partition.

What we are afraid of is that someone may have login access (forcefully or similar) to the device and can do as he wish.

We would like to hear any suggestions of prior experiences.

Thanks & regards,
Ertan

drgeoff
Posts: 11105
Joined: Wed Jan 25, 2012 6:39 pm

Re: Secure app running on Pi

Tue Dec 10, 2019 11:06 am

ertank wrote:
Tue Dec 10, 2019 9:35 am
Hello,

We have a compiled application, GUI, running on Pi. We will be putting that application on an SDCARD/Flash Disk/mSATA and giving away with Pi itself.

We would like to protect that application to be copy/paste to another place for reverse engineering, etc.

We thought of;
1- Use a strong password for user pi like 16 characters with everything mixed.
2- Use LUKS and put out application on an encrypt partition.

What we are afraid of is that someone may have login access (forcefully or similar) to the device and can do as he wish.

We would like to hear any suggestions of prior experiences.

Thanks & regards,
Ertan
This question has been asked and answered here several times. If there is physical access to the card, all bets are off.
Quis custodiet ipsos custodes?

deepo
Posts: 605
Joined: Sun Dec 30, 2018 8:36 pm
Location: Denmark

Re: Secure app running on Pi

Wed Dec 11, 2019 8:26 pm

Putting a password on the RPi won't stop anybody from changing it:
https://howtoraspberrypi.com/recover-pa ... pberry-pi/

The above should also rule out your number 2 solution, as it's now possible to have access to a running device.

But that doesn't mean you can't do anything about trying to secure your application.
You should be able to at least make it a little harder to copy your application.

How about locking your application to a specific serial number?

Code: Select all

grep Serial /proc/cpuinfo
Serial          : 00000000f7dd7cf3
I don't know how many you are planning to give out, so maybe it's not a feasible solution.

/Mogens

User avatar
thagrol
Posts: 3518
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Secure app running on Pi

Wed Dec 11, 2019 10:02 pm

Locking to a serial number won't work. Older model Pi may have the same serial number as another Pi (serial numbers are randomly assigned at the factory, enough Pi have been produced that duplicate serial numbers are a thing) though the risk of that is small. Not sure if the problem also exists on the 4B.

It's also a support issue (assuming there will be any support). If the pi or SD card fail you can't simply swap the failed part over.

There isn't really a way to make your software 100% secure. Encrypted files have to be decrypted in order to run/use them. Likewise encrypted filesystems. Compiled langauges (including langues that compile to bytecode like java and python) can be decompiled - that won't get your exact source code but to someone sufficiently skilled that won't matter. Programs in interpreted languages are often just text files.

The trick is finding a balance between the valve of your product, the cost to you (in time, effort and money) of your proposed solution, and the cost to a bad actor to work around it (again, in time, effort and money).

There's a reason why many software producers have moved to online activation via a license key. And why Microsoft (at least as I understand it) tie that license key to a hash that uniquely identifies your hardware for windows. Or to an onboard ID chip in the case of the large OEM PC makers.

Hardware dongles used to be a thing for software protection, don't see that anywhere as much now.
Arguing with strangers on the internet since 1993.

trejan
Posts: 2559
Joined: Tue Jul 02, 2019 2:28 pm

Re: Secure app running on Pi

Wed Dec 11, 2019 10:34 pm

thagrol wrote:
Wed Dec 11, 2019 10:02 pm
Locking to a serial number won't work. Older model Pi may have the same serial number as another Pi (serial numbers are randomly assigned at the factory, enough Pi have been produced that duplicate serial numbers are a thing) though the risk of that is small. Not sure if the problem also exists on the 4B.
I suspect the Pi 4 serial numbers are also randomly assigned. IIRC they had to set the highest nibble in the serial number to 1 (10000000XXXXXXXX) to signify it is a Pi 4 so the online shop wouldn't issue codec licenses for it.

The Pi 4 MAC addresses however are assigned from a database and should be unique. For a Pi 4, you should be able to key it from the MAC address but you need to use the VC mailbox to read tag 0x00010003 to get the address. The MAC address on eth0 can be changed in Linux so you shouldn't read it from there. This won't work for the earlier Pi models however as the onboard Ethernet MAC address is generated from the serial number which as mentioned can clash.
thagrol wrote:
Wed Dec 11, 2019 10:02 pm
Hardware dongles used to be a thing for software protection, don't see that anywhere as much now.
Still lots of them around but it is usually for niche or specialist but expensive software packages like Xilinx Vivado. Thankfully they're USB these days instead of the bad old days of parallel port dongles.

bjtheone
Posts: 916
Joined: Mon May 20, 2019 11:28 pm
Location: The Frozen North (AKA Canada)

Re: Secure app running on Pi

Thu Dec 12, 2019 3:48 pm

trejan wrote:
Wed Dec 11, 2019 10:34 pm
thagrol wrote:
Wed Dec 11, 2019 10:02 pm
Hardware dongles used to be a thing for software protection, don't see that anywhere as much now.
Still lots of them around but it is usually for niche or specialist but expensive software packages like Xilinx Vivado. Thankfully they're USB these days instead of the bad old days of parallel port dongles.
It really depends on what the app is, the price point and the use case and how secure you want to make it. I used to manage CAD design environments for large telecom companies and had the dubious pleasure of interacting with pretty much all the licensing variants.

Likely the easiest relatively secure method to implement is a USB based dongle. If you can live with your one copy being useable on multiple machines via moving the dongle.

At the high end, something like FlexNet gives you the most options. I took a quick look and FlexNet Embedded should be available for ARM based systems. Flex works fabulously on x86 Linux. I never have used it on ARM.

However this does NOTHING to prevent a user from accessing the SD and copying the software for reverse engineering. That is a much more difficult challenge since you need to encrypt the software and lock down access. Raspbian really was not built with this in mind.

User avatar
thagrol
Posts: 3518
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Secure app running on Pi

Thu Dec 12, 2019 6:18 pm

Yeah. The only secure code is the code that you don't run and don't distribute.

One very real problem with securing code on the Pi is that a JTAG interface is available on the GPIO and, according to this https://pdfs.semanticscholar.org/887e/0 ... d5b606.pdf it can be enable by modifying the kernel image in the boot partition.

With that all bets are off as, AFAIK, JTAG allows you extremely low level access to the CPU and RAM. Encrypting your software won't help as it'll likely be decrypted when it's loaded into RAM (line by line decryption as the code is being run would be a huge performance hit if it's even possible, and if it is you could probably still get the decrypted code out of the CPU cache).

Like I said, you need to find a balance between risk, cost, and reward.

Make the entire OS read only, glue in the SD card and put the entire thing is a steel box that is welded shut. That'll probably make the effort required to hack it more than it's worth (unless your software is really, really, high value). Of course it also ups your production and support costs. Any system failure and you're looking at sending out an entire new unit instead of one part or a software patch.
Arguing with strangers on the internet since 1993.

bjtheone
Posts: 916
Joined: Mon May 20, 2019 11:28 pm
Location: The Frozen North (AKA Canada)

Re: Secure app running on Pi

Thu Dec 12, 2019 11:19 pm

Depending on what hardware you need access to, you could just clip off the GPIO header, insert your encrypted SD card and epoxy dip or pot the board. This is what they used to do to cable boxes, which made them a total pita to mod. Likely could package it for less than $100 USD.

It comes down to what your software does, what is the margin, and use case. Bottom line, if someone really really wants to get it, your licensing scheme will get broken, Certainly could get cracked licenses for all the high end CAD software (Synopsys, Mentor, Cadence) back in the day and they were very motivated and used high end licensing systems. I doubt it is any different now.

Given that there are countries that have no ip laws, if there is a market for it, it will get copied, cracked and resold. I suggest finding a balance between deterring causal theft and spending tons of money on a complex and annoying to your users solution.

dustnbone
Posts: 348
Joined: Tue Nov 05, 2019 2:49 am

Re: Secure app running on Pi

Fri Dec 13, 2019 3:33 am

Without full hardware and OS support for something like Secure Boot, and a proper implementation of it with signed code throughout, there's really no chance of doing anything beyond making it inconvenient for someone who wants to copy your code.

Anything encrypted is going to have it's key in memory at some point, and reading contents of memory in Linux is trivial.

I don't see the Pi foundation making this a hardware priority anytime, ever.

ejolson
Posts: 5784
Joined: Tue Mar 18, 2014 11:47 am

Re: Secure app running on Pi

Fri Dec 13, 2019 5:11 am

ertank wrote:
Tue Dec 10, 2019 9:35 am
We would like to hear any suggestions of prior experiences.
The common way to protect code these days is to run the part that needs to be secured in the cloud.

Prior experience can be learned from the case study of GEOS. As described here
Maciej Witkowiak and Michael Steil wrote:The original GEOS was copy protected in three ways:
  • The original loader decrypted the KERNAL at load time and refused to do so if the floppy disk was a copy.
  • Desktop assigned a random serial number to the kernel on first boot and keyed all major applications to itself.
  • To counter tampering with the serial number logic, the KERNAL contained two traps that could sabotage the kernel.
The result from the users point of view
is described here where
James Esch wrote:GEOS for the Commodore had some fatal flaws that doomed it as a viable 8-bit operating system. The problem can be reduced to two words: copy protection. The GEOS “boot disk” was copy protected. Out of the box, they only gave you one backup boot disk. Berkeley Softworks really outdid themselves in making the boot disk virtually impossible to crack. Although other applications were not copy protected, they were “keyed” to your boot disk, meaning that after “installing” your newest GEOS application, you wouldn’t be able to use those apps unless you booted with your original system disk. This kept GEOS out of the hands of pirates, but it was incredibly short-sighted.

Have you ever seen a 5.25″ floppy disk? It is obscenely easy to mutilate. Have you also seen and heard a 1541 disk drive? Especially one that needs an alignment? A 1541 can perform complex drum solos on your disk that would make Buddy Rich jealous. What this means is that the entire brilliant achievement of software expertise that was GEOS, this user friendly operating environment coded and packaged to make your life easier, was a ticking time bomb waiting for the fateful day that your boot disks got trashed, making ALL of your work irretrievable.
While SD cards are quieter than floppy disks, they are notoriously the least reliable component of most Raspberry Pi configurations. For this reason, the above analysis and commentary on copy protection applies equally well, in my opinion, to the Pi. In particular, it should be possible to employ the same ideas to secure a program on the Pi; however, the perceived problems with copy protection and the resulting decrease in reliability are also the same.

Return to “Advanced users”