Encrypt locally stored data

[mrphs]

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]

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

[mrphs]

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

[hellais]

@mrphs indeed, thanks 👍

[anadahz]

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]

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

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

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]

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)

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

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?"

[koushikcs562]

Hello everyone,
I'm interested in working on this issue. I recognize the prior discussion points regarding the cost/benefit tradeoff, SD card wear concerns, and the challenge of key management for unattended reboots.
My Approach:
Re-evaluate the Tradeoff: Given that this issue is from 2015, I'd like to quickly re-assess if modern Raspberry Pi operating systems or available filesystems offer better, simpler, and more reliable low-overhead encryption options (e.g., perhaps leveraging existing kernel modules or simpler solutions than FUSE).
Focus on Key Management: I believe the critical path is finding a pragmatic solution for key storage that balances security with the requirement for unattended boot. This may mean using a simple, un-removable key derived from the host device itself (acceptable for protection against casual physical theft, though not high-security seizure), or focusing on application-level encryption as an alternative to full-disk/partition encryption.
Application-Level Alternative: I'll first investigate the feasibility of application-level asymmetric encryption (as mentioned by @joelanders) for the OONI reports themselves, as this avoids most key management issues related to unattended boot and SD card wear entirely.
I intend to look into the modern feasibility of these options and propose the lowest-overhead solution that still provides a meaningful security improvement for data at rest.