Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: mulletman87 on February 17, 2016, 04:48:57 AM
-
Hi all,
After the OS boots, it will need to pull some packages, etc. from persistent storage. I have read the wiki and understand what it does.
My question is, would it be possible to encrypt that persistent storage and then, during the OS boot process, fire a script that connects, authenticates (user/pass) and fetches the decryption key from a cloud server (via https/ssh, to prevent MITM attacks) to make it readable by the OS? I could always then run another script to restart any services that depended on that encrypted volume as they would then have access.
My end goal is to stop people from copying data from that encrypted partition, even when its plugged into a Windows/linux box (they an see the OS partition, that's fine).
Is there a more graceful way of doing it? I have done research, even found this (https://www.tindie.com/products/sales_st/software-serial-protection-for-raspberry-pi-2/) but don't know if I could get it working on picore.
-
It's possible, but would need a lot of complexity. You either need to embed all that in the boot logic, before the tce partitions are scanned for, or to launch it after boot, and handle loading packages there; all this needs to be remastered into the initrd on the unencrypted, small fat32 boot partition.
If you mean to ask about encryption options, ext4 has built-in encryption support, and dm-crypt can encrypt entire partitions, though I don't know if these are enabled in the pi kernel config. Loop-aes is an external kernel patch that can do loopback files or partitions.
-
If you mean to ask about encryption options, ext4 has built-in encryption support, and dm-crypt can encrypt entire partitions, though I don't know if these are enabled in the pi kernel config.
ext4 encryption is enabled if piCore-7.0 kernel. However I have never tested it. User feedback welcome :)
-
@mulletman87,
Why you like to encrypt the partition? No reason why not to copy it and share.
It's basic idea of this distro and forum, it's user contributed and not commercial.
Guess that you like to use piCore for commercial use with no respect to his.
May be better that you'll focus on Win10 which is focused on the commercial use.
-
If you mean to ask about encryption options, ext4 has built-in encryption support, and dm-crypt can encrypt entire partitions, though I don't know if these are enabled in the pi kernel config. Loop-aes is an external kernel patch that can do loopback files or partitions.
Thank you!
@mulletman87,
Why you like to encrypt the partition? No reason why not to copy it and share.
It's basic idea of this distro and forum, it's user contributed and not commercial.
Guess that you like to use piCore for commercial use with no respect to his.
May be better that you'll focus on Win10 which is focused on the commercial use.
I have zero need to encrypt ANY part of tinycorelinux, which my users will be feel to access, if they want. However, when it comes to packages that I have paid thousands of dollars for, I do not want those accessible by anyone who removes the SDcard from the RPi and plugs it into another PC.
If you mean to ask about encryption options, ext4 has built-in encryption support, and dm-crypt can encrypt entire partitions, though I don't know if these are enabled in the pi kernel config.
ext4 encryption is enabled if piCore-7.0 kernel. However I have never tested it. User feedback welcome :)
This sounds like exactly what I need. How would it work if they took the SD card out and plugged it into another PC? I presume that tinycorelinux would be accessible (which is perfectly fine) but anything on the encrypted ext4 partition would not?
-
I've read the ext4 encryption is per-directory. So they can see it's an ext4 partition and mount it, but without the key, they can't list the contents of any encrypted dir, or access any files in them. If the encrypted dir is the root, it will look like an empty partition, I guess.
-
I've read the ext4 encryption is per-directory. So they can see it's an ext4 partition and mount it, but without the key, they can't list the contents of any encrypted dir, or access any files in them. If the encrypted dir is the root, it will look like an empty partition, I guess.
Thank you! Since the decryption key would be stored within tinycorelinux (which is in the "open" partition), surely that means that they could extract the key from there? Honestly though, even if this is the case, its a pretty much "out the box" solution for the problem that I had so might just go with it. Thanks for your time!
-
Place the key on usb flash memory.
-
What is the goal? To protect program to reverse engineering, protect copy to run on anauthorized hw, etc. ?
You can use a dedicated hw key connected to USB, I2C whatever also.
-
Thank you! Since the decryption key would be stored within tinycorelinux (which is in the "open" partition), surely that means that they could extract the key from there?
Why would it be stored in a file? Your original post says it would be fetched each boot from a server, and then kept in memory?
-
Hi mulletman87
Once the files/filesystem is unlocked, whats to stop someone from copying them then?
-
What is the goal? To protect program to reverse engineering, protect copy to run on unauthorized hw, etc. ? You can use a dedicated hw key connected to USB, I2C whatever also.
The latter. I just want to stop people cloning my entire system. While they are welcome to copy all parts of tinycorelinux, 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.
Why would it be stored in a file? Your original post says it would be fetched each boot from a server, and then kept in memory?
This is true. However, that was just a proposed solution, if it could be kept on the device, that would be ideal. Fetching it from an external server would eliminate a large security hole though. The more I think about it, I think that the hw key might be the way to go, at least until I can hire a programmer to write that external key retrieval system.
Hi mulletman87, once the files/filesystem is unlocked, whats to stop someone from copying them then?
Well this is the issue that I am brainstorming. When the SDcard is plugged into the device, yes it will be decrypted but they cannot access the data due to access credentials (logins, etc.). When the SDcard is removed and plugged into a windows laptop for example, they cannot access the data because they dont have the decryption key (either from the hw device or from the cloud server during boot).
Just brainstorming at the moment to be honest, still trying to find the best solution.
If you had to do it, what method would you personally use?
-
hi mulletman87,
I have been an IT Manager for lots of years and seen lots of security devices and encryption keys.
Here is a list of tips learnt from experience.
1. Make sure you make the purchasers aware of the security device during the sales process.
Then, when they have to get approval from their IT Manager he/she will get a "no" and this will solve any chance of stealing your software.
2. Make the security device easily removable from the computer.
This allows the user to take the security device home and the lose it. Ensure when they ask for a replacement you tell them that they will have to repurchase the software and security device at full price because you don't really believe them.
This means people in the office can unplug it and leave it somewhere where no one can find it.
3. Make sure the security device interferes with other software.
Users love this.
4. Make sure the security is not compatible with other security devices.
It fun to watch users swap security devices, until they lose it.
5. Make sure it is keyed to one computer.
This is a great one. Nobody ever upgrades their computer do they. Computers never fail. Ensure there is no one in your office to support the transfer of the security device on Friday afternoon when the tender is due out on Monday morning.
6. Make sure the security device is flimsy enough to break.
It's great to have non-productive users while a new one is being issued, but only after the return of the old one. And it only took 2 days to get accounts approvable for funds. Oh.. the courier lost it, bummer.
7. Make sure the security keys are reasonable complex.
Hackers like a bit of a challenge before the break it and publish on a newsgroup for free.
8. Make security keys only work for one computer, ditto #5
9. Make usre the secuity measures are so painful that the company will ditch the software for the opposition.
regards
Greg
-
@Greg Day made, thanks for the lols ;D ;D ;D ;D ;D ;D ;D
-
Hi all,
Does anyone have any further thoughts on reply #11?
-
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 :-)
-
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.
-
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.
-
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! :)
-
@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.
-
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:
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.
-
Exactly what Casey talking about in this video.
Intel SGX
https://youtu.be/8eULB8uMIuc
-
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: 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 :)
-
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?
-
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.
-
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 :P
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).
-
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..
-
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.