Filesystems simply don't work write-only; it's read-only or read-write. In a filesystem you
cd somewhere and
ls somewhere, all of these are read operations. If you can only encrypt (write) but not decrypt (read) you're simply not getting anywhere (with a filesystem on a block layer).
So for you, it's files or pipes, or perhaps using a block device like a tape drive (without filesystem, no arbitrary seeks/reads), or archives like tar created in a completely linear fashion that never need to re-read some old data.
If your application supports piping output, you can go with
openssl or other programs that support public/private key encryption/decryption.
Generate a key just for this:
gpg --quick-generate-key myproject
(Of course, you can also use existing keys, if you prefer).
echo Hello World. instead of
echo Hello World | gpg --batch --encrypt --recipient myproject > file.encrypted
gpg --batch --decrypt < file.encrypted > file.decrypted
The machine that does the encrypting only needs the public key. On decrypting, if your private key has an additional passphrase, you will be asked to provide it (if
gpg did not remember it for you).
GnuPG offers a myriad of options, this should be explained with a lot more detail here http://www.gnupg.org/ and in various Linux wikis.
Whether this is practical or not... encryption is computationally expensive, a dashcam might not be up to the task (in addition to the video workload it already has to do), ...
Supposedly there were some digital cameras that worked this way (take encrypted photos you can only view at home). Not sure why this idea is not more popular or how secure whatever method they used really was.