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.
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...
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
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.
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.
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).
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.
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.)
If possible, I'd use two flash drives, mirrored with soft-raid, for storage. One clearly visible in the dashcam, the other hidden somewhere deeeep inside the car with an USB extender.
Why? Because if a cop/other driver ever gets mad at you and forces you to hand over the flash drive, you still have a copy.
Also, I'd add two microphones to the project, one for exterior sound, one for interior (e.g. to prove what exactly has been said, or in case of a crash if other drivers have honked, or if an ambulance had its sirens on).
And, I wouldn't use a Pi, but rather something supporting SATA, because USB flash drives tend to have low lifecycles when constantly overwritten.
If you're going to have multiple cameras, the next step is to combine them into one spherical image. Fujitsu has been doing this since 2010.[1] With four cameras, you can get the full vehicle perimeter. Other companies now offer such a capability.[2]
This is neat, but I would worry that something which is intended to be "set and forget", without the usual screen, would fail silently - especially with such a custom build. How are you assuring that it is functional and recording?
If it's not done automatically it won't routinely happen though. I wonder about this with some sensors at home. Some of them routinely ping me with status but other commercial ones are pretty much fire and forget. I can certainly set calendar entries to run tests but you're better off with things are self-testing in some manner.
Maybe I missed it in the instructions, but how does the system handle the shutdowns? Does he manually shut it off each time, before USB power is turned off, or does it just handle the power cut-off gracefully? I worry that the file system will get corrupted after a while.
There was some discussion about this on a pi board a while back; it seems that the only safe way to handle power-off is to (1) have a battery on the pi, and (2) catch the USB power-off signal and then shutdown gracefully.
At least, that's how the Chinese dash cams seem to work. They all have rudimentary batteries that last about one minute unplugged from the power outlet.
He wrote about handling shutdowns in another post on his blog.[1]
> For the automatic shutdown I have used a 12V programmable timer in combination with an optocoupler.
> When the car is powered the the timer gets triggered and is starting the power supply for the Raspberry pi,
Dashcam pi will get started and will do its job. When the car is turned off the optocoupler triggers the
GPIO pin of the raspberry and starts a shutdown. After 15 seconds the timer is shutting down
and the raspberry pi is powerless.
Very nice! Love it that he uses Arch, I also used to use Arch for everything, and I also run a RPi tutorials website.
I switched though, because the only questions I'd get was of people using my commands on Raspbian and getting confused. I think the RPi audience is full of beginners that don't understand the difference between distro's and the kernel. Of course one should do as one pleases and Arch is the nicest distro if you known what you are doing, imho.
No sudo by default! I forgot that was even a difference between Debian and Raspbian.
I'm probably just not the beginner I used to be anymore, I can look at a Pacman package name and figure out if it's going to work for Apt, and I'm used to my GUI breaking every few months because I like to run proprietary Nvidia drivers.
This is a really cool project, and I'm always thinking about doing something similar with RPi or other small computer. In the past, I had built my own x86-based CarPC for music/media/GPS/automation/etc.
However, the rise of dash cams are better solution for video as they are much cheaper, easier to install and run, and video is much higher quality. The cheap $45 dashcam has 1080p with 30fps, no need to buy 12v relay timer and deal with other power issues. Also the video on dashcams outperform the webcam attached to the RPi due to RPi's slow USB2 (we're talking 15fps at best).
For more complete and capable product, I'd suggest using something with USB 3.0 port, or possibly a used laptop, which provides enough processing power to record multiple videos at higher quality, and at the same time, has built-in battery, provide power management (using serial port/other hack to handle automatic shutdown and WOL for reboot).
Note: A lot of the functionality of CarPC has been deprecated due to mobile device/phone/tablets, but it's still fun to have a PC running in a car.
Actually, I think if you have all the parts already (i.e. RPi, webcams), this makes a lot of sense. Creating a Frankenstein system out of existing components would be interesting, and cost would be zero.
I have played around with this a little, using the camera pi module gives good results, but means you must mount the pi close to the camera. I wanted to use USB cameras but the USB bus on the pi is too slow. From a single USB webcam I was getting around 15fps. The newer pi's may have a faster USB bus.
My raspberry pi is great fun but a bit prone to failing randomly and very sensitive to input power levels, not sure I'd trust it if it was hooked up to car electrics.
That's not a problem. It isn't that hard to design (or buy) a circuit to provide clean power from an automotive power source. The "carPC" community has been doing this for ages.
This is a good idea. The costs from getting a pulled over for no reason is a big deal. I gave been pulled over for no reason, so many times, you'd think I wasn't in America.
I bought two $15 Chinese dash cams. The same ones that are being peddled for 40 bucks plus S&H on t.v.
I bought the second one just in case the first one goes down.
A dashed lane marking means that both sides may temporarily use the other lane to pass -- provided that they can see it will be safe. A solid center line means you cannot do that. A double line with one side solid and one side dashed means that the dashed side may attempt to pass, not the solid side.
All of these things become more clear once you realize they are primarily about sight-lines.
Did you watch the video in the article? He is driving with the middle of the car over the dotted line. If I had to guess, I'd say it's a two-way one-lane road with bike-lanes on either side that you can enter when cars are coming towards you.
Cool project, although I would not advise using dashcams if you are involved in an accident the police can subpoena the footage which could potentially be used against you (in both criminal and civil suits).
If you do run a dashcam I would suggest having one that does not record audio and only keeps the last 5-10min of footage on record because GL explaining to the cops why you have been driving like a jackass just before the accident even if it had nothing to do with it.
Right. It's no accident (badum-psh!) that Russia and China are full of expensive cars with dashcams. Or even just regular cars with dashcams. The benefits far outweigh the penalties for the vast majority of dashcam users.
Dashcams in Russia are used because there is a huge problem with insurance fraud people would just either get hit intentionally or even jump on the hood of standing cars and claim they were hit.
The police and the legal system in Russia wouldn't care about your dashcam if you want to get out a of a jam a bribe would work just fine (I've been pulled over in plenty of places where I had to pay dues, mostly Asia - Thailand, Philippines, Burma but it's not that uncommon in Russia and some Balkan states either), insurance companies on the other hand do like them very much.
I am really wondering why you are pushing so hard against dashcams. Dashcams (along with bodycams) are making corruption in the justice system much harder to pull off. You can find a ton of videos on YouTube exposing corruption in law enforcement around the world, including the United States. This is not mass surveillance! This is a personal record of travel that isn't vacuumed up into the warrantless surveillance machine and twisted to serve an evil purpose (like Verizon's call record database, among many others). Your argument -- that your video could be subpoenaed and you might have to explain why you were driving like a jackass -- is weak to the point that I am beginning to suspect an ulterior motive. Why are you pushing so hard against dashcams?
Nothing wrong with having a camera to record when you are being pulled over, having a device that constantly records everything and is pretty much turned on by default is disadvantageous to both your privacy and your interests.
I've also said that I personally would recommend a dash cam which records the last 5 min and no audio, this should be enough as a deterrent and will allow you to provide any evidence if required while not keeping anything on the record that could damage you.
And please do not compare dashcams to bodycams, because ?I'm pretty sure you would not want to live in a world where everyone is wearing a bodycam that is recording 24/7, or even suggest people to walk on the street while recording everything with their phones.
When you make a record of anything you should be aware that what ever you document can be used against you, or against another party at any time and that your agency to maintain the privacy of that record is limited both from a legal and practical point of view.
Uhm. Bodycams -- specifically that term, "bodycams" -- have exactly one context right now, and that's the context in which law enforcement wears them while on duty. And I do think that bodycams are a great thing that should be required as part of being a law enforcement officer on duty.
You still haven't explained yourself beyond the same old "what you record can be used against you" argument, which as I've said before, is weak. I think this will be my last reply, since there is absolutely nothing being gained here in this discussion.
The simple argument is that if you were involved in an accident with a dashboard camera it can be used against you, if you tamper with it after you are stepping into the territory of spoliation of evidence.
Ask any lawyer and they'll give you a golden rule - do not create records that might be used against you unless you are compelled to do so.
If you have a dashboard camera then know the risks and mitigate them as I've mentioned before having a camera that overrides it's footage after a short period is good enough simply because you then need to perform a deliberate act to save that footage this reduces the liability that a dashboard camera can present in cases where it might have recorded something you might not want to become public.
Furthermore dashboard cameras that do not record sound in the cabin are also preferable because the last thing you want is you on record being distracted by arguing with a passenger or switching radio station or bad mouthing some driver that cut you off and those things are considerably more common than people think.
A dashcam that overwrites footage in a short period may be of no use if you're unable to stop the recording because you've been injured in an accident.
And anyway, if I'm at fault and that is recorded on the camera then that is okay with me. The camera will at least give an indisputable account of the events it recorded, whereas our human memories can be ... inaccurate.
Speed, okay... and sometimes it's safer going faster than the posted limit (IE with the flow of traffic). However, if you're missing stop signs, you're definitely doing something wrong - either driving too fast or not paying attention.
Sounds different from "missing" stop signs. Sadly, I see people come to rolling stops at most stop signs... so much so that it makes me feel like I'm the only one wasting my time doing it right.
It's one of the many things that make me wild about the idea of letting computers do the driving. Zipper-merging, slowing to time lights instead of stopping, and no rubbernecking are wonders of the future I can't wait to enjoy.
Which must be why "stop means STOP!!!" was repeated very forcefully by the driving instructor and the friendly police officer multiple times during my driving course.
In what country or state? In California they definitely mean you must make a full stop. Also people seem to have forgotten any of the rules of priority at stop lights. (Straight and right always come before left. Right on red is below everything else.)
You'll be surprised just how many traffic infraction every driver is doing every day.
We all had that case where a stop sign that was hidden behind a tree (not everyone lives in the US where they paint them on the road ;)) or misses the school/children crossing sign or any other temporary sign that was put there due to works or w/e.
I cannot imagine paying so little attention you miss stop signs, even those behind trees. If I am driving and come to an intersection and I don't see a stop sign and there is a tree where the stop sign usually would be you better believe I'm looking for that post in the ground to make sure there really isn't a stop sign. Then if I don't see one I look at the cross intersection to make sure THEY have the stop sign.
Well, if you're at fault, then fess up. If your are more responsible than most, then statistically, a dash cam will be on your side. And judging from this thread, that shouldn't be too hard.
A 'Stop' sign means you must come to a complete stop before proceeding.
Or rather: a 'Stop' sign means you must come to a complete stop before proceeding or risk being fined if you are caught.
It is possible to come to a complete stop before proceeding and still cause an accident by failing to give way. Contrariwise, it is possible to proceed through a 'Stop' sign in a safe manner without coming to a complete stop.
In Australia I'm aware of a few intersections with traffic lights that are signed 'Left Turn on Red Permitted After Stopping'[1], which is proof that, at least some of us, are capable of acting like adults, and experienced drivers, and disregard the light / sign when it is safe to do so.
Rules hey. I know one local outdoor swimming pool that is signed 'No balls'. No balls in an outdoor swimming pool? It makes me want to drive through the stop signs.
Australian roads have some pretty whacky speed limit signs, things like: 60 50 40 30 20 80 70 100 School Zone 70 40 30 25.[2]
I don't understand your point. Follow the rules of the road, it's not that hard. If the rules allow left turn on red that'd great. That's different than not obeying other traffic signs.
How long does it take for them to subpoena you? That is if I were in an accident, and they don't physically confiscate the memory drive, could you extract any video that supports your case and delete the rest before they request it?
I figure this happens with police dashcams and bodycams all the time.
If the police is on the scene they don't even need a subpoena they can search the car and confiscate the memory card.
If you destroy the contents of the card it doesn't look good, that fact can be brought up against you (tampering with a car that was involved in an accident especially one with casualties could potentially be a crime on it's own).
If you present only the snippets that support your case the other party will petition the court to for you to present the unedited video if you cannot the entire thing will most likely be thrown out (the other side might be able to present the fact that you have attempted to present an edited video and have discarded the raw footage which will likely not fair well with a jury).
Not to mention that having the video it self could put you at risk of perjury or being found in contempt if you try to do anything after the fact.
They need probable cause to do that in most places. Also, there's nothing stopping you from quickly dismounting it before you pull over and shoving it under the seat, saying you don't have it if asked what the dangling wire is, and refuse to consent to a search if the officer doesn't believe you. If your car is forcibly searched anyway, it will almost surely be inadmissible, and might even help your whole charge get thrown out.
I was pretty clear that I am referencing only cases when a vehicular accident has occurred in that case they have all the probable cause they need.
BTW if the officer doesn't believe you it could lead to a probable cause, please do not base your strategy on having to give a false statement to a law enforcement agent.
A police officer cannot search your car under the presumption that you might be lying about something that might connect to a dash cam that might have been installed and running at the time of the accident that you might erase if he lets you go. Unless someone's died at the scene or was seriously injured or your appear to be engaging in some illicit activity like driving stoned, it's a pretty tenuous defense against your 4th amendment rights first to search your car, then seize your property. Not to mention the complications of the right not to incriminate yourself.
"...in emergency situations which threaten public safety or the loss of evidence."
Which gives a police officer the cause they need to search the car if they believe there has been a documentation of the accident and you do not come forth when questioned.
Beyond that if an investigative officer has been called to the scene of a car accident they do have the right to search all vehicles involved.
In fact they have several rights beyond that including towing your car to the police impound and doing what ever they need to it, in any accidents in which there were casualties it's standard procedure as the car will be checked mechanically by the police.
But the officer can't search the vehicle because of that. And if he does, you can most likely get your whole case tossed out for a search without probable cause.
Probable cause is a tricky issue, if the police officer thinks you are hiding something they can claim probable cause and if they actually find what they were looking for their cause has just been validated.
But this is irrelevant because i was specifically talking about accident when they do not need cause to search your car.
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.