5 ms·

Thanks for sharing. Little bit off-topic question for HN: is there any encrypted Linux filesystem which can be mounted in write-only mode using only the public

Thanks for sharing. Little bit off-topic question for HN: is there any encrypted Linux filesystem which can be mounted in write-only mode using only the public key, and read-write mode using the private/public key-pair? I think that kind of filesystems would be very useful for dashcams and security cameras owners for their privacy.

pmontra 11y ago
I found this http://www.arthy.org/wocfs/ http://www.arthy.org/wocfs/ I have no idea if it really works. If you give it a try would you mind letting me know?
robryk 11y ago
It'd be hard to imagine how that should work on filesystem level (if I can't read contents of any directory, how do I figure out which directory do I add a newly created file to?). OTOH, on the file contents level this seems very much doable. Sadly, I am unaware of any general purpose implementation of such a thing (encfs doesn't do anything of this kind).
- tw04 11y ago
  You create a new directory on start that is based on the date/time - which you know will always be unique.
  - ars 11y ago
    > which you know will always be unique. Which you hope will always be unique. Raspberry Pi's don't have internal clocks. Time starts over on every reboot.
    - widdma 11y ago
      The GPS module can give you time, but it's probably easier and cheaper to have an RTC. E.g.: http://www.futurlec.com/Mini_DS1307.shtml http://www.futurlec.com/Mini_DS1307.shtml
cnvogel 11y ago
For the pretty limited usecase of a "record only" dashcam, you might consider recording in chunks. Create an ephemeral key for a symmetric encryption in advance, encrypt this ephemeral key with the public-key method of your choice and store somewhere. Then encrypt one minute of recording using this ephemeral key. I don't know if gnupg is performing good enough on all architectures, but in principle it can handle everything in one go, and it works exactly as described just above. ~ dd if=/dev/zero bs=1M count=50 | gpg -e -r 0x6AC3E4EC >encrypted.dat 50+0 records in 50+0 records out 52428800 bytes (52 MB, 50 MiB) copied, 0.486881 s, 108 MB/s (Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz) If you use mpeg transport streams, you can even cut at arbitrary positions (to make, say, each file exactly 50 MiB large). When you play back, decoders will catch up as soon as they find the proper markers. So your encryption pipeline doesn't even have to know much about video...
- cnvogel 11y ago
  Just pondered... there might be everything already be installed in a typical linux system, "split" does the right thing and can pipe into a command. Probably not the most efficient (making several copies of the data), but certainly enough for a proof-of-concept. $ dd if=/dev/urandom bs=1M | \ split -b5000000 -d -a4 --verbose \ --filter="gpg -e -r 0x6AC3E4EC >\$FILE" \ - recording_ executing with FILE=recording_0000 executing with FILE=recording_0001 executing with FILE=recording_0002 (...) • -b500000 split at 50 megabyte input file size. • -d decimal suffixes (0001, ... else aa..az..zz) • -a4 : suffixes of length 4 (0000) • --filter="" : filter through pgp, intended output file is in variable $FILE • - : read stdin • recording_ : prefix output files with this string $ file *recor* recording_0000: PGP RSA encrypted session key - keyid: 8F74FAFF 29C8C7C2 RSA (Encrypt or Sign) 2048b . recording_0001: PGP RSA encrypted session key - keyid: 8F74FAFF 29C8C7C2 RSA (Encrypt or Sign) 2048b . recording_0002: PGP RSA encrypted session key - keyid: 8F74FAFF 29C8C7C2 RSA (Encrypt or Sign) 2048b . (....)
logicallee 11y ago
I read your requirements. So, there's an analog loophole: in order to "write", the filesystem has to receive the data to be written - otherwise, it's untestable (if it doesn't get the data to be written it could write whatever it wants and pass all tests) which is a roundabout way of saying that if it doesn't get the data it can't possibly work. So it has to get the data. At that point it could be saved if the filesystem is modified (patched) to exfiltrate it. So we have to assume that you kind-of trust the filesystem not to be patched. But if the filesystem is not modified, though, that means you're fine with the path that that data takes all the way until your filesystem writes it -- however, in this case your requirements are 100% met by encrypting to the public key and writing that out. #jakobdabo's requirements #include <pgp stuff> #include <filesystem stuff> public key = arg0 private key = arg1 read_file(filename){ if (have_private_key) try decrypt(private_key, read(filenename)) return result except "didn't work" else "I wasn't called with a private key." } write_file(filename, data) towrite = encrypt(filename, data) //encrypted metada inside try write towrite except "didn't work" so this should meet all of your requirements. If you wanted the filesystem to do stuff like hide whether a file is even modified, hide timestamps, etc etc, those are almost impossible. Consider: I want to determine whether anyone is accessing a server at the moment. Server is idling, with sockets listening to answer web queries. Suddenly 5,000 Reddit users show up and look through the site, generating lots of logs which nginx dutifully saves - only you're saving it in your encrypted filesystem. Now. How would you make it so that the fact that all of this traffic is being saved is hidden? The updates to the drive image would have to happen like clockwork regardless of what was happening. But this isn't a reasonable requirement, as the amount of entropy entering the drive is bigger while Reddit is hugging it than normal. You couldn't make it so that you are saving as much information as at top load. so what do you do? Reduce the top average to some level that you can continuously fabricate? It doesn't make sense. So you wouldn't hide whether any data was being saved by the dash-cam at all. but it's easy to save an encrypted version. the dash cam doesn't even need the private key. but you do have to trust the software running on it. (for example to correctly do the encryption and not also write the underlying data somehow.)
Natanael_L 11y ago
Not quite the same thing, but forward secure sealing is relevant: https://lwn.net/Articles/512895/ https://lwn.net/Articles/512895/ You can always also use a smartcard type device to sign your files. Then a reboot (power cycle) will revoke signing capability until unlocked again.
Sanddancer 11y ago
You could always just pipe it through gpg or the like. Just encrypt using the public key, and you can't decrypt unless you have the private.
- widdma 11y ago
  If you really wanted it to work like a file system, you could write a passthrough FUSE module which pipes files through GPG before writing to the underlying file system. This seems like a good start: https://www.stavros.io/posts/python-fuse-filesystem/ https://www.stavros.io/posts/python-fuse-filesystem/
ChuckMcM 11y ago
No need to do it at the filesystem level, just do it at the file level. You can encrypt using the public key in the dashcam, when you want to recover the video you bring the removable media to a system where you can use the private key to unlock it. Since there is often hardware support for AES you can use the public key to encrypt an AES key for the current segment, then when you get it home use the private key to recover the AES key and then use that to recover the video. The existence of the files is pretty obvious but they won't generally be decryptable.
- jakobdabo 11y ago
  The advantage of doing this at the filesystem level is that you don't need to modify every piece of existing software which writes sensitive data (video/images/logs/etc.). I'm thinking of an EncFS type stackable solution (as suggested by @robryk) based on FUSE because you could copy the encrypted files from the upper level filesystem when needed (without remounting the lower level filesystem in read-write mode) and examine them on an air-gapped computer which holds the private key. The disadvantage of this type of stacked solution is that it wouldn't be possible to implement plausible deniability.

pmontra 11y ago

I found this http://www.arthy.org/wocfs/ http://www.arthy.org/wocfs/ I have no idea if it really works. If you give it a try would you mind letting me know?

robryk 11y ago

It'd be hard to imagine how that should work on filesystem level (if I can't read contents of any directory, how do I figure out which directory do I add a newly created file to?). OTOH, on the file contents level this seems very much doable. Sadly, I am unaware of any general purpose implementation of such a thing (encfs doesn't do anything of this kind).

tw04 11y ago
You create a new directory on start that is based on the date/time - which you know will always be unique.
- ars 11y ago
  > which you know will always be unique. Which you hope will always be unique. Raspberry Pi's don't have internal clocks. Time starts over on every reboot.
  - widdma 11y ago
    The GPS module can give you time, but it's probably easier and cheaper to have an RTC. E.g.: http://www.futurlec.com/Mini_DS1307.shtml http://www.futurlec.com/Mini_DS1307.shtml

cnvogel 11y ago

For the pretty limited usecase of a "record only" dashcam, you might consider recording in chunks. Create an ephemeral key for a symmetric encryption in advance, encrypt this ephemeral key with the public-key method of your choice and store somewhere. Then encrypt one minute of recording using this ephemeral key. I don't know if gnupg is performing good enough on all architectures, but in principle it can handle everything in one go, and it works exactly as described just above. ~ dd if=/dev/zero bs=1M count=50 | gpg -e -r 0x6AC3E4EC >encrypted.dat 50+0 records in 50+0 records out 52428800 bytes (52 MB, 50 MiB) copied, 0.486881 s, 108 MB/s (Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz) If you use mpeg transport streams, you can even cut at arbitrary positions (to make, say, each file exactly 50 MiB large). When you play back, decoders will catch up as soon as they find the proper markers. So your encryption pipeline doesn't even have to know much about video...

cnvogel 11y ago
Just pondered... there might be everything already be installed in a typical linux system, "split" does the right thing and can pipe into a command. Probably not the most efficient (making several copies of the data), but certainly enough for a proof-of-concept. $ dd if=/dev/urandom bs=1M | \ split -b5000000 -d -a4 --verbose \ --filter="gpg -e -r 0x6AC3E4EC >\$FILE" \ - recording_ executing with FILE=recording_0000 executing with FILE=recording_0001 executing with FILE=recording_0002 (...) • -b500000 split at 50 megabyte input file size. • -d decimal suffixes (0001, ... else aa..az..zz) • -a4 : suffixes of length 4 (0000) • --filter="" : filter through pgp, intended output file is in variable $FILE • - : read stdin • recording_ : prefix output files with this string $ file *recor* recording_0000: PGP RSA encrypted session key - keyid: 8F74FAFF 29C8C7C2 RSA (Encrypt or Sign) 2048b . recording_0001: PGP RSA encrypted session key - keyid: 8F74FAFF 29C8C7C2 RSA (Encrypt or Sign) 2048b . recording_0002: PGP RSA encrypted session key - keyid: 8F74FAFF 29C8C7C2 RSA (Encrypt or Sign) 2048b . (....)

logicallee 11y ago

I read your requirements. So, there's an analog loophole: in order to "write", the filesystem has to receive the data to be written - otherwise, it's untestable (if it doesn't get the data to be written it could write whatever it wants and pass all tests) which is a roundabout way of saying that if it doesn't get the data it can't possibly work. So it has to get the data. At that point it could be saved if the filesystem is modified (patched) to exfiltrate it. So we have to assume that you kind-of trust the filesystem not to be patched. But if the filesystem is not modified, though, that means you're fine with the path that that data takes all the way until your filesystem writes it -- however, in this case your requirements are 100% met by encrypting to the public key and writing that out. #jakobdabo's requirements #include <pgp stuff> #include <filesystem stuff> public key = arg0 private key = arg1 read_file(filename){ if (have_private_key) try decrypt(private_key, read(filenename)) return result except "didn't work" else "I wasn't called with a private key." } write_file(filename, data) towrite = encrypt(filename, data) //encrypted metada inside try write towrite except "didn't work" so this should meet all of your requirements. If you wanted the filesystem to do stuff like hide whether a file is even modified, hide timestamps, etc etc, those are almost impossible. Consider: I want to determine whether anyone is accessing a server at the moment. Server is idling, with sockets listening to answer web queries. Suddenly 5,000 Reddit users show up and look through the site, generating lots of logs which nginx dutifully saves - only you're saving it in your encrypted filesystem. Now. How would you make it so that the fact that all of this traffic is being saved is hidden? The updates to the drive image would have to happen like clockwork regardless of what was happening. But this isn't a reasonable requirement, as the amount of entropy entering the drive is bigger while Reddit is hugging it than normal. You couldn't make it so that you are saving as much information as at top load. so what do you do? Reduce the top average to some level that you can continuously fabricate? It doesn't make sense. So you wouldn't hide whether any data was being saved by the dash-cam at all. but it's easy to save an encrypted version. the dash cam doesn't even need the private key. but you do have to trust the software running on it. (for example to correctly do the encryption and not also write the underlying data somehow.)

Natanael_L 11y ago

Not quite the same thing, but forward secure sealing is relevant: https://lwn.net/Articles/512895/ https://lwn.net/Articles/512895/ You can always also use a smartcard type device to sign your files. Then a reboot (power cycle) will revoke signing capability until unlocked again.

Sanddancer 11y ago

You could always just pipe it through gpg or the like. Just encrypt using the public key, and you can't decrypt unless you have the private.

widdma 11y ago
If you really wanted it to work like a file system, you could write a passthrough FUSE module which pipes files through GPG before writing to the underlying file system. This seems like a good start: https://www.stavros.io/posts/python-fuse-filesystem/ https://www.stavros.io/posts/python-fuse-filesystem/

ChuckMcM 11y ago

No need to do it at the filesystem level, just do it at the file level. You can encrypt using the public key in the dashcam, when you want to recover the video you bring the removable media to a system where you can use the private key to unlock it. Since there is often hardware support for AES you can use the public key to encrypt an AES key for the current segment, then when you get it home use the private key to recover the AES key and then use that to recover the video. The existence of the files is pretty obvious but they won't generally be decryptable.

jakobdabo 11y ago
The advantage of doing this at the filesystem level is that you don't need to modify every piece of existing software which writes sensitive data (video/images/logs/etc.). I'm thinking of an EncFS type stackable solution (as suggested by @robryk) based on FUSE because you could copy the encrypted files from the upper level filesystem when needed (without remounting the lower level filesystem in read-write mode) and examine them on an air-gapped computer which holds the private key. The disadvantage of this type of stacked solution is that it wouldn't be possible to implement plausible deniability.