Encrypt the persistent storage

[mulletman87]

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.

[curaga]

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.

[bmarkus]

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

[jgrulich]

@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.

[mulletman87]

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?

[curaga]

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.

[mulletman87]

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!

[patrikg]

Place the key on usb flash memory.

[bmarkus]

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.

[curaga]

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?

[Rich]

Hi mulletman87
Once the files/filesystem is unlocked, whats to stop someone from copying them then?

[mulletman87]

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?

[Greg Erskine]

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

[mulletman87]

@Greg Day made, thanks for the lols 

[mulletman87]

Hi all,

Does anyone have any further thoughts on reply #11?