lepidopter
lepidopter copied to clipboard
TheTorProject
Encrypt locally stored data
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.
This was not part of the original requirements, but we can see what can be done perhaps.
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.
@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.
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.
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.
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?"