Encrypt the persistent storage

[netnomad]

hi mulletman87,

why don't you want to put all your sensitive data in a encrypted container-file.
cryptsetup offers a very practical approach to store data and even move and copy this encrypted container-file to further devices, even with other operation systems.
this contaimer-file is only opened and unencrypted, when needed.
in my opinion a password stored somewhere else and an automated decryption-proccess do not fit to my sense of security...

keep on hacking :-)

[coreplayer2]

I just want to stop people cloning my entire system. While they are welcome to copy all parts of tinycore linux, i don't want them taking all my hard work (scripts, some custom packages, etc.) and cloning it to their own Raspberry Pi. The dedicated hw key is an idea and I think it will definitely work, based on my research, thank you

As per reply #11  After files are decrypted by whatever method and loaded into the file system they are available to anyone who has access.   "thank you for sharing" :p


If you don't want to share then don't give the boot media to anyone and allow no internet access, even then...    It all depends on how desirable it is to have?  If someone wants it, they probably already have it.

[Rich]

Hi mulletman87
First rule of copy protection, there's no such thing as copy protection, only countermeasures. The best you can hope
for is to make it as difficult, painful, and time consuming as possible.

That said, here are a few ideas. Tie the software to the serial number of the CPU. Don't read the serial number from
/proc/cpuinfo , retrieve it from the CPU directly if you can. Don't have the serial number in your program in clear text.
Avoid scripts used for protection, too easy to patch. Compiled (C or C++) programs run through  sstrip  require much
more work to bypass. Implement a loader in your program that that decrypts it as it loads it into RAM. There probably
different levels of obfuscation you can use like modifying function pointers at run time and using multiple levels of
pointer indirection to make it difficult for someone to disassemble and trace the program. Though doing so makes it
easier to introduce bugs.

In the end, a determined individual with the right tools who knows how to use them, will likely figure out how to
bypass any security checks you implement.

[mulletman87]

These are all fantastic solutions, I will spend a couple days researching how to actually do them (still very new to this but I understand what is being said). Just two quick questions though, I just want to clarify them.

If I encrypt the partition (that is used for persistent storage) using something like cryptsetup (or just ext4 encryption, I presume you can specify where it can find the key? If it generates it's own, is there a default place where it is kept?) and then use the /proc/cpuinfo number as the decryption key:

1) If someone puts that sdcard into an sd card reader, will they be physically unable to view the files/contents of that encrypted partition?

2) If they realize that its probably using that cpuinfo #, how easy is it for them interrupt the boot sequence and pull that number? And if it is easy, perhaps I can pull a few unique numbers from the raspbery pi 2b and combine it?

I understand that these are only countermeasures, probably not a massive obstacle for very skilled individuals but I am just curious, thanks for your time and support!

[mulletman87]

@Rich, I just re-read your message, great idea to pull the serial directly, was going to update the post above but modify has disappeared, I presume the post is too old. I will definitely add some of your other ideas into the mix, thank you.

[Rich]

Hi mulletman87
When someone requests a copy your program they would have to send you the serial number of their CPU by
providing the result of:

Code: [Select]

cat /etc/cpuinfoYou would need to incorporate a provision in your build system for you to enter that serial number so it gets
compiled into the software, making it unique to that one CPU.

[patrikg]

Exactly what Casey talking about in this video.

Intel SGX

https://youtu.be/8eULB8uMIuc

[mulletman87]

Hi mulletman87, when someone requests a copy your program they would have to send you the serial number of their CPU by
providing the result of:

Code: [Select]

cat /etc/cpuinfo - You would need to incorporate a provision in your build system for you to enter that serial number so it gets compiled into the software, making it unique to that one CPU.

I actually will be selling the Pi, already prebuilt with all necessary stuff loaded (which makes things way easier), failed to mention this before (my bad). Could I be so bold as to ask how you would actually do it, using cryptsetup / serial number to encrypt the persistent partition? It is my task for this weekend but a little guidance command wise would be great if anyone is already skilled at doing this, will be happy to report back and build an entire solution page for future community members

Exactly what Casey talking about in this video.
Intel SGX - https://youtu.be/8eULB8uMIuc

Thank you, will watch tonight

[LemuelSabia]

Hi, just saw this post when I'm working on a similar problem -- selling an encrypted pi with important stuff inside.

For encryption per se, I think a more manageable solution is to set up an encrypted loop device on the existing tinycore persistence partition (there are a lot of online guides for doing this). That way you can just put the standard setup code in bootsync.sh without altering any tinycore internals.

However, after some discussion with our team, we're no longer very keen on hardware-tied encryption. A problem is that if they could take out your sd card, they could just replace it with a standard raspbian and get whatever hardware information they need for the decryption.

Currently I'm thinking along these lines:

- Glue the card to the slot. I bought some "sealing glue", but I probably won't have the balls to try it before getting the software part finalized... Ideally, if the glue is stronger than the card, we could make it really hard for someone to take out the card without destroying it?

- Just open source the "protection code", but put the important a-million-dollars part on a meticulously logged server and make sure everyone knows that. On the server side, we could hire someone to read the log every day and make a phone call every time a new IP address appears. On the pi side, we download things to ramfs on boot, provide access over a network interface, and notify the server / reboot the pi whenever a hardware change is detected.

Any other thought on this topic?

[curaga]

SD cards can fail, or the fs can be corrupted, then you'd be up to replacing the entire unit. A remote server "SaaS/cloud" thingy would be reasonable.

Still, all these antifeatures trying to work around the users, I don't know what to feel.

[mulletman87]

Still, all these antifeatures trying to work around the users, I don't know what to feel.

Yeah it is a little of a touchy subject, I completely get it, especially with FOSS. But, my goal is just to stop another COMPANY from literally copy pasting what equates to hundreds and hundreds of hours of work and then getting their own clients using your blood sweat and tears. Honestly, I personally think that maybe 1 in every 100 will even want to know what is running on the Pi.

However, after some discussion with our team, we're no longer very keen on hardware-tied encryption. A problem is that if they could take out your sd card, they could just replace it with a standard raspbian and get whatever hardware information they need for the decryption.

Honestly, that is where the obfustication would come in. So you can take the CPUID and a couple OTHER unique things about each Pi, combined together to provide the decryption key. Then it is not as easy as "it is probably the CPUID". You could even add a couple unique numbers in there (that only your company knows exist) to make it even harder.

I am giving it another go tomorrow and Sunday, it is hard to find time, especially with a family who demands (and rightly so) some attention on the weekend hehe

If anyone would like to share how they would extract the CPUID and get something like ext4's built in encryption or crypt-setup to use it (on the persistent storage), please let me know, I would really appreciate it (even though I am willing to dive headlong myself).

[coreplayer2]

But, my goal is just to stop another COMPANY from literally copy pasting what equates to hundreds and hundreds of hours of work and then getting their own clients using your blood sweat and tears.

Sorry to give you bad news but this goal is so flawed.   The simple matter is;  the file system is completely open to the very people you are attempting to exclude.   I'd go further than that and say at the top of a list of folks who would definitely know how to extract and copy your work in minutes, are the very people you are trying to exclude..

You need to place a considerably larger obstacle in their path.   It appears the best and probably the only solution to this issue have already been posted here and as far as I can tell has been ignored.    As a reminder then, rewrite all your work in C then compile it with a specific hardware key.   
As has been said already nothing is impossible,  therefore the level of difficulty must out way the benefits of reverse engineering.   Frankly,  encrypting the volume leaves the file system totally accessible after boot-up to anyone with local or network access, is like handing your secrets away on a plate..

[curaga]

Yeah it is a little of a touchy subject, I completely get it, especially with FOSS. But, my goal is just to stop another COMPANY from literally copy pasting what equates to hundreds and hundreds of hours of work and then getting their own clients using your blood sweat and tears. Honestly, I personally think that maybe 1 in every 100 will even want to know what is running on the Pi.

Is that not what copyright law is for? Their product containing yourbinary that displays "(C) You" on startup is pretty willful infringement. IANAL.