RED-Key (security proposal for RED cameras)

[Joel Kaye]

Then a process on the post side of things where RED's tools and plug-ins could lock-out rogue cameras

RED could do that. I believe all footage has camera ID info embedded in the R3D files now. They'd just need to make it part of the SDK so any app that used the SDK to render could check it. Of course the software would have to phone home via the internet for updates. Hmmm.... that's pretty easily defeatable.

I think the USB port could hook to a fingerprint scanner. Once every 30 days you validate the camera via that.

The protection needs to be just enough of a hindrance to cripple the camera as to make it unusable at some point. The whole idea of RED adding protection is a good one. Might lower insurance rates and certainly would make me feel better owning one. And it's REDvolutionary thinking.

 

[JanneJansson]

We also have to accept that there are plenty of skilled hackers in the world. There is no protection scheme that can not be thwarted.

Stolen camera? ...That's what insurance is for. Just be sure to notify RED so that the camera will be marked and never allowed to be upgraded, repaired or traded in.

Yes, 2 very good points.

Just look at iphone. It have more then 50 sequrety locks, and that did'n stop hackers.

My insurance will cover a theft, but NOT a camera malfunction and set back production!

IMO, this is based on a good idea, but in real world will just make life harder for the real owners and stimulate R1 hacking.

 

[Peter Majtan]

There are parts of this idea that are good and we just may steal ..

Feel free Jarred...

but on a whole this is something that would take an incredible amount of resources and planning to implement properly... and time and resources are unfortunately something that we do not have alot of extra right now.

Anything I can help with? You could actually outsource the key-generating SW to 3-rd party. As I have explained above - the SW is useless without the personal info and password from the end user. You will only need to concentrate on the firmware implementation, which should not be that difficult...

Peter

 

[Bob Gruen]

The EPIC brain should incorporate a GPS and mobile phone and send the coordinates to Red every time the camera is booted.

Bob

 

[Stephen Williams]

The EPIC brain should incorporate a GPS and mobile phone and send the coordinates to Red every time the camera is booted.

Bob

Hi Bob,

Many of the jobs I work on are secret at the time of shooting, I don't think my clients would except details of locations to be passed on to a 3rd party.

Stephen

 

[Dylan Reeve]

It seems like a good idea in theory.

However there would need to be some method of re-activating the camera without the 'key' so that when you have a legitimate hire that is phsyically out of range, and they run over time, you can get them going again over the phone.

Or if the 1st AC happens to lose the SD card, they need something to keep them going until they can get a replacement.

But overall I think a time-limited SD-key based security system isn't a bad idea at all.

 

[Mohammed El Sharqawy]

some nice guy will find a way to hack your security system... don't bother yourself.. if such a camera with that price is stolen.. some mind working over it is not an issue..

 

[Dylan Reeve]

some nice guy will find a way to hack your security system... don't bother yourself.. if such a camera with that price is stolen.. some mind working over it is not an issue..

That is certainly possible, and I know a few guys who would be ideal candidates for the job. However as a security measure for day-to-day rentals it probably has benefits.

However, without access to the camera's code, and only one side of the encrypted key setup, it would be significantly harder to break, and could conceivably have to be individually broken for every camera, rather than having a general bypassing tool.

The bigger problem comes with the sorts of things I suggest, which is allowing a method of bypassing the security without a key-card for practical purposes. If such an option exists for legitimate purposes, it presents the best option for bypassing the system overall.

 

[Jarred Land]

Feel free Jarred...



Anything I can help with? You could actually outsource the key-generating SW to 3-rd party. As I have explained above - the SW is useless without the personal info and password from the end user. You will only need to concentrate on the firmware implementation, which should not be that difficult...

Peter

outsourcing security is definitely something we would not do.. once 3rd parties have the tools to make ( and break ) the key, it kinda defeats the whole purpose..

 

[Conrad Hunziker]

That is if You make the key-generating SW web-based. This will not fly with end-user as many times You are on a location far away from internet. The SW needs to be locally on Your laptop, but it is useless when steeled - because You will need the personal data and correct password to generate the new key...

The problem with it being software based is there there is NO way to disable to software from making a legitimate key once the software is released. Say for example I own a camera and use the software to make the key. I then sell the camera to a third party and tell Red about it. I disconnect my computer from the internet and then generate a new key. How does the software know NOT to make a new key?

You need to have a central point where the software can lookup if the key is valid for a particular camera. The only way to do that is by looking in Reds database via a internet connection. So if you have a internet connection, you might as well use a web browser.

And related to that is security of the software. Once the software is released, it is rather trivial to reverse-engineer the code to generate valid keys for ANY camera. It would be entirely possible for some motivated hacker to watch the software in action and create valid keys for any camera he wants. By keeping the key-generation behind a website, you avoid that process entirely. As a side point, if the software were on a laptop that would mean it would need to interface somehow with the database of cameras & owners. Thats another security risk that red would need to assess and maintain.

The third thing about generating software is that there are so many platforms that you would need to release it for - Mac, Windows, etc. Keeping that code in line would take a fair amount of time, let alone debugging it, etc for each platform. As mentioned earlier Red simply doesnt have the time to do this. So by having a web interface, they only need to do it once.

And one final point about "being far away from the internet". Ive been literally around the world in paces you would think has no internet. Yet I was able pretty easily to find internet in the middle of India, high in the mountains in Peru, in the Amazon rainforest and even in a temple in Thailand. At no time was I more than 30 minutes away from the internet.

Actually that programming is not that difficult - You just abandon the boot sequence and hang it on the warning (see the diagram). What will be difficult is the programming for the SW to generate the key and for the camera to recognize it. Difficult, but doable and very much in the interest of RED and the owners...

But the programming of it IS difficult. Thats the whole point. Regardless of where in the boot sequence you have it, you still need to wake up the camera, identify what items are attached, initialize those (like the LCD, EVF or HD-SDI), get everything up and running and THEN decide to look at the key from the SD card. You cant just abandon the boot sequence at all - because thats where the processing is done!

They programing way to do this is to add a hook in the code at a point where the camera is up processing, but before the image is captured from the sensor. I dont know exactly how Red has programmed their software, but I do know that this would be one of the last things done before releasing the camera to the user.

Make all the flow charts you want, programming it IS hard and WILL take time. And there really is NO second chance in terms of doing this correctly. It would need to be done right the first time, or Red will have a lot of angry users and cameras to fix.

 

[Conrad Hunziker]

Good point Stephen. The SW could be just made to "phone home" to RED and the owner only if the footage date is AFTER the camera was stolen. So when including the stolen RED ONE numbers in the SW (or an online database to be checked periodically by the SW), they would need to include the date when it was stolen as well. This will not affect the previous footage...

Peter

The issue here is that its rather trivial to modify the footage to any date in the past or future. Its just header info in the R3D file.

In addition, that means that every piece of software would have to have a local database of rogue camera IDs and dates it happened. Sure it could update this from time to time, but unless theres a local database, just unplug your computer from the net and edit your rogue footage all you want.

Really, the best way to do it would NOT be with any tools that lock out the footage. As much as I know you guys want to get the bad guys, it just really is not the bet way to handle footage. I know I certainly dont want to add to render times just because I have a slow internet connection.

 

[Conrad Hunziker]

I don't like it either, I would much prefer time/date scenario. But in the current RED ONE's this is rather easy to circumvent. If You disable it in the menu, then it can't be adjusted for time-zone travel with the crew, etc... Given the situation I think that the # of boots is the safest way for now.

Ahh - but if you are playing with the menus, it would certainly be easy to disable setting the date in the camera at all. In fact, the way the camera works now is to set the date to UTC and then modify it based on your time zone. So if you just disable the setting of the time and load in your timezone as you travel, there would be no issues.

 

[Conrad Hunziker]

It seems like a good idea in theory.

However there would need to be some method of re-activating the camera without the 'key' so that when you have a legitimate hire that is phsyically out of range, and they run over time, you can get them going again over the phone.

Or if the 1st AC happens to lose the SD card, they need something to keep them going until they can get a replacement.

But overall I think a time-limited SD-key based security system isn't a bad idea at all.

Maybe thats an addition to the system. Have a system where you dont need to send a key but just a update file to the 1st AC, who would then load it in the camera. The update key would re-enable the camera and automatically set it for a certain amount of time. Using the same key generation system you could generate a update key which would have encoded in it the new expire date. Nothing in it would allow any adjustments, just enter the update key, boot and the camera would update itself. Remove the key, reboot and shoot!

So in essence you would have 2 types a keys. A master key which would enable the security system and a update key would would enable a extension to the amount of time until the camera turns to a pumpkin again.

 

[Dylan Reeve]

Maybe thats an addition to the system. Have a system where you dont need to send a key but just a update file to the 1st AC, who would then load it in the camera. The update key would re-enable the camera and automatically set it for a certain amount of time. Using the same key generation system you could generate a update key which would have encoded in it the new expire date. Nothing in it would allow any adjustments, just enter the update key, boot and the camera would update itself. Remove the key, reboot and shoot!

So in essence you would have 2 types a keys. A master key which would enable the security system and a update key would would enable a extension to the amount of time until the camera turns to a pumpkin again.

I think essentially you need something as a backup where you can tell someone to do something over the phone and that can get it going. Any requirement for communications beyond a simple phonecall, or tools beyond fingers is presenting the potential for a situation where someone with a legitimate issue (lost card, or in the middle of nowhere pas deadline) is locked out.

So perhaps a manual override system that could be enabled on a per-camera basis?

I'm no security expert (but I know a few of really really good ones) but I can see a workable situation where each camera has a unique signature (like a PGP key). When you get the camera from RED you get a signature file that is tied to that camera. The key-gen software then uses that unique per-camera key to generate the auth file to be put on the SD card.

The situation I'd envisage would be that you'd be able to generate a super-user SD card. With this inserted you could access the menu options that control it. Enable/Disable the system, set options (perhaps the possibilty and window for non-card manual override). Once that card has been removed, if the system is enabled it will only boot with a valid keycard inserted (or with a manual override, if enabled).

Even if the generation software were to leak (and in fact it could be a free download on the website) it would be useless without the signature file tied to the specific camera. The only avenue for bypassing it would be to modify the binary Firmware file and re-flash the camera, a process which could be made near impossible.

The limitation should be date-based. With the system enabled only the super-user would be able to freely set the date/time. A regular user would only be able to modify the date and time within a small window (to allow for timezone corrections etc).

 

[Conrad Hunziker]

Even if the generation software were to leak (and in fact it could be a free download on the website) it would be useless without the signature file tied to the specific camera. The only avenue for bypassing it would be to modify the binary Firmware file and re-flash the camera, a process which could be made near impossible.

But the software solution doesnt account for camera sales. It would be entirely possible for me to have a camera, sell it, and still use the software to generate keys to that camera. I could steal back my own camera and use it. You would need to have a solution that accounts for who owns it, according to Reds database.

And again, the software needs a code base, time to code it, and maintain it over several platforms. Red just doesnt have the time.

 

[Hrvoje Simic]

metadata > RED security system

metadata > RED security system

In terms of safety I was thinking more like using footage metadata.

There could be a system with stolen camera database, and as software gets updated, REDCODE plugin for each system just scrambles up the picture and adds "STOLEN CAMERA" watermark.

Any updated software would make the camera useless and stolen RED's would show up pretty soon, plus it would be a cool marketing thing for RED, making a camera with it's own security system stamped in its footage.

 

[Shawn Booth]

Hola Peter!

Love the "SD key" lock idea.

I use the SD card to transfer looks between cameras...

 

[Peter Majtan]

The problem with it being software based is there there is NO way to disable to software from making a legitimate key once the software is released. Say for example I own a camera and use the software to make the key. I then sell the camera to a third party and tell Red about it. I disconnect my computer from the internet and then generate a new key. How does the software know NOT to make a new key?

You have completely missed the boat - no offense...

The whole idea is that THIS IS THE WAY to prevent the SW from generating proper key. You (and many others here) keep forgetting that to generate the proper key You need to have the personal information and private password of the owner - which is incorporated into the key. Therefore EVEN if You have the best SW hackers in the world - and You managed to reverse-engineer the SW and find out how the key is generated - You will still miss the crucial piece of information - the personal info and private password of the user... Unlike computers where there are some ways to by-pass the login password - the RED ONE has no other way to access the firmware. Therefore without the password (and the personal info) all Your hacking is useless.

This also addresses the sale of the camera. Once You are selling the camera You use Your generated password to disable the RED Key. Then the new owner generates a new key based on his personal info and private password. Once he activates the security Your old key is useless as the camera will only look for the new key...

Unless there is any other way to access the cameras firmware - this security is bullet-proof...

Peter

 

[Peter Majtan]

outsourcing security is definitely something we would not do.. once 3rd parties have the tools to make ( and break ) the key, it kinda defeats the whole purpose..

Jarred - see my post above. You could even release the source-code for the password generating SW to public and it will be useless. The key needs the personal info and password from the owner to generate (and incorporate this data into) the key. It's like having a complex password to login into Your computer. Sure there are SW that could try to random search for Your password and personal data to generate the key - but for each "try" they will need to boot the camera and check if the password is OK. This is simply impossible. I would dare anyone to break the key and give them my Red One if they do... PS: I am also a programmer...

Peter

 

[Monday Sunnlinn]

well, don't kill me, but... I voted no because I think that the chances of losing the SD card are better than this actually deterring a theft or a theft even occuring. And it doesn't protect your accessories from getting stolen, which when you add them up, are a significant percentage of the over all worth of the kit. Especially when you add in lenses.
So I guess I just don't think it's worth it to over complicate the process and increase the length of time it takes to boot the camera in the first place.

How many times have I been screwed in one form or another by a rental house/producer communication screw up? More times than I haven't been. I don't always get a chance to pick up the gear and inspect it myself(and I don't need to hear about how this shouldn't be the case, the fact of the matter is that last minute, low budget, thrown together shoots where you have to fly in the night before and have PA go get the gear while you are doing a site survey do happen...) So how do I know that the rental house included the correct sd card, or programmed it all correctly? It's not an issue when you are 10 minutes away, but what about when you are 2 hours drive into the desert or it's winter in wisconsin and you can't even see the roads?

And the idea that any firmware system(no matter how well thought out, which this one admittedly is) can't be circumvented or hacked is just not realistic. All it takes is someone hacking into a red computer to get the SDK and release it into the wild. I can't think of one security system that has actually never been circumvented or breached.