Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypt locally stored data #9

Open
mrphs opened this issue Oct 26, 2015 · 10 comments
Open

Encrypt locally stored data #9

mrphs opened this issue Oct 26, 2015 · 10 comments

Comments

@mrphs
Copy link

mrphs commented Oct 26, 2015

So if I understand things correctly, if an upload fails for whatever reason, OONI will keep the data on the SD card until it finds room to upload them. We need to make sure this data sits encrypted on the card by default.

@hellais
Copy link
Member

hellais commented Oct 27, 2015

This was not part of the original requirements, but we can see what can be done perhaps.

@mrphs
Copy link
Author

mrphs commented Oct 27, 2015

Let's brainstorm on it a little bit and figure the cost/benefit ratio...

@hellais
Copy link
Member

hellais commented Oct 27, 2015

@mrphs indeed, thanks 👍

@anadahz
Copy link
Member

anadahz commented Oct 28, 2015

Encrypting local stored data increases the chances for SD card and consequently possible more SD card failures. We could add this as a feature; on the raspi-config but I 'll say not to the main lepidopter distribution.

@hellais
Copy link
Member

hellais commented Nov 18, 2015

@mrphs should we defer this to future releases? IMHO the tradeoff is not worth the work + the gain.

@ghost
Copy link

ghost commented Dec 16, 2015

@mrphs @hellais @anadahz I might be able to look into this - using a FUSE container with the crypto loop module might be sufficient in order to ensure that data at rest is encrypted. I agree that the use of locally encrypted storage currently exceeds the cost/benefit ratio, though.

You'd probably have to ensure that ooni-probe always runs in a container to accomplish what I've described.

@darkk
Copy link
Member

darkk commented Aug 18, 2016

I doubt that encryption will significantly increase chances of SD card failures. AFAIK, there is no write amplification, so what's the reason for increased failure rate?

Another question is key management. How should we store the secret if the RPi should be bootable in unattended way? E.g. due to temporary power failure.

@joelanders
Copy link
Contributor

Stuff could be asymmetrically encrypted so only the OONI collector/pipeline/whatever can read it? (and not, like, someone seizing a computer running ooni-probe, if that's important)

@ghost
Copy link

ghost commented Aug 20, 2016

@joelanders We're talking about two different considerations if I'm not mistaken. @mrphs is indicating that ooni-probe reports should be encrypted locally before they're sent to an OONI collector. While we could asymmetrically encrypt all of the things, this would be sub-optimal as we'd need to encrypt every file individually.

@joelanders
Copy link
Contributor

I don't understand; two things == 1) encrypted filesystem, vs. 2) application-level asymmetric encryption?

I was throwing out 2) as an alternative to 1) in response to darkk's "How should we store the secret if the RPi should be bootable in unattended way?"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants