RED-Key (security proposal for RED cameras)

[Dylan Reeve]

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.

Nothing is going to stop theft, of course. If you're going to hire out tens of thousands of dollars of gear to people who are essentially strangers, then it's a risk you take. But something like this could certainly reduce the appeal of such a theft.

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?

Certainly that is a potential problem, which is why I suggested the idea of some form of configurable time-limited manual override.

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.

RED already has a very strong interest in protecting the intellectual property they have tied up in their camera. I presume their code is pretty well protected.

I can't think of one security system that has actually never been circumvented or breached.

There are certainly many systems which can't be broken without inside knowledge. PGP (on which this system could be based quite easily) has not been broken.

 

[Roberto Lequeux]

something simple would be just fine... a pin would probably be the most simple form but it would kill the start up time factor

though perhaps if it asked for the pin every so often, and when did it booted up normal but you then know that you had to enter it before the next time you boot... how about that? maybe it can start up three times after it first asked for it, reminding you how many you had left, 3, 2, 1...

 

[Conrad Hunziker]

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

Ahh yes. Clearly an internet forum. Let the belittling begin.

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.

Besides the key code you get from Red, what makes your information for camera #1212 (randomly picked number) and my information different? Say I owned that camera. How is my information valid and yours not?

Or think about it the other way. What prevents the camera from validating that I am the owner? The only way to do that at any time is for Red to say this person is the owner, here is his info, and heres his key.

You can then use that key to encrypt your own info if you like. But the simple fact is if you let the validating go down to the software, which is what you are proposing, then I give that software a week before its hacked.

For someone who is a programmer, you are not thinking very securely. You need to limit the amount of exposure the software generates to outside hackers. That is the whole point of security!

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...

But how does that firmware know who is valid? How does that firmware know that its the correct user giving it the details? Say I sold the camera today, and 4 minutes later I steal it. How does it know not to let me in?

Your software idea really has some fundamental flaws that it cannot get around.

The last of them, which you have not yet addressed, is time. When is Red going to devote developer time from all the other software they are developing to develop this software for Mac/Win and test it and secure it?

The web key idea is not only more secure, easier to deploy and easier to manage.

 

[Peter Majtan]

Conrad - I have no intention to "belittling" You - what ever that means... I am speaking here with all due respect and I just don't know how much clearer can I explain this for You to understand. One more try:

Lets say for the sake of the argument that the code (the simplest version) contains two groups of 8 alpha-numeric digits. The first part is generated by RED at the time of sale of the camera and is specific to that particular camera only. Lets say fi8Yh2j9 This code can be always requested online from RED (via Your private login) in case You loose it. The second group is your private password. Lets say 4hs8Uhh2. You input this two codes into the RED-Key SW and it will format the connected SD card with the appropriate code hidden inside a mumbo-jumbo string. The camera at this point is not RED-Key activated. You booth with the SD and (according to the diagram on page 1) You get normal boot, but You have extra RED-Key submenu in the UI. The camera knows from the portion of the code generated from the key sent by RED that it is indeed a valid RED-Key card. When You activate the security feature - it copies the mumbo-jumbo string into its internal SS memory - which includes both the portion generated from the RED key and the portion generated based on Your password. Only the camera knows where to look in the mumbo-jumbo for the "right" info. (I know what you are about to say, but I will get to this in a second, please be patient)

From now on the camera is protected and will only respond to the SD card with the exact same mumbo-jumbo string on it.

Now - if You loose Your SD card - just buy a new one. Input into the SW generator the key from RED (download it again if You have lost that too...) and Your personal password (here You are out of luck if You have forgotten it) and the SW will generate new RED-Key SD card with the "correct" mumbo-jumbo string. Repeat when necessary...

Now when You are selling the camera (or just want to deactivate the security) - simply insert the SD card with the "correct" string and camera will give you the access to the menu to deactivate the security. The string is removed from the camera. Sell the camera. Inform RED about the sale and RED will give an access to the RED portion of the key in the new user's account. RED could also generate a completely new code compatible with this particular camera only. (I know, just a second please...)

New owner fires up the SW, inserts the RED key and HIS OWN password. The SW generates new SD card. The camera knows (based on the red-portion of the code) that it is valid RED-Key card and add the security sub-menu to the UI. Once the new owner activates the security, the new mumbo-jumbo string is copied to the camera and the camera now responds ONLY to this string. Hence the previous owner's key is useless...

This is IT in a nutshell. Now Your points:

- I hope by now You understand that not only the string is unique to a particular camera, but also to the individual owner based on his password...

- That also explains how "my" string is valid and "yours" is not for my camera...

- You can only hack the SW that generates the string. But this is useless because You won't have neither the RED-generated key for the specific camera (which is done by separated SW at RED HQ's only), nor will You have the camera owner's password. Even if You somehow got Your hands on the SW from RED and reverse engineer it - You will be still missing the owner's password to generate THE EXACT SAME string now loaded into the camera. So all Your hacking comes down to Your ability to "guess" the owners password. Even with 8-digit alpha-numeric combination (case sensitive) You, as a programmer, get a rough idea how many possibilities there are. Now add to this the fact that You would HAVE TO generate the string and boot the camera for EVERY SINGLE try - this renders it realistically unbreakable. Please don't tell me You don't understand this part...

- About Your question "How does that firmware know who is valid?" - that is obviously based on the RED-generated portion of the key. But this is only useful when the camera security is not activated. Complaining about this is like trying to explain Your insurance company why You car got stolen if all You did was leaving the door open and the key in the ignition... Pardon my sarcasm...

I would really like You point out any "other" flaws You think this solution might have. I know only about one: If the owner forgets his password and the security is "armed". There could be no by-pass option for this situation, as this will create the missing Achilles' heel. But this is no different from someone forgetting their password to a "FileVault" in the OS-X for example. Your data is lost forever. Period. You can hardly call this a "flaw"...

[EDIT] In the above case the camera would have to go to RED HQ's to firmware reset (at the cost of the owner of course...). Worst case a board change - still cheaper the loosing Your camera... [end of EDIT]

There is the last issue You have mentioned - the time needed to do this. Once You really understand what I have explained above - You will see that there is no complex programming required (since as You have correctly pointed out anything can be hacked). Even a simple generator will do. The strength of the system is in the use of an personal password by the owner in generating the pass string. Only by breaking that You will be able to break the RED-Key solution. Good luck with that...

Peter

 

[Dylan Reeve]

In general this type of system is implemented something like this:

- Camera firmware has code to generate a hash of some sort from various identifying elements unique to the camera hardware (at the very least the CPU would be able to provide this unique code. I suspect other parts could be incorporated).

- Using this hash you generate two signatures (or two parts of a single one). One part belongs to the camera, one gets given to the camera owner when they purchase along with a predefined password.

- The SD card, when you produce it, stores one part of the signature one-way encrypted by the provided password. When it's read by the camera the stored inital password is used to decrypt the signature. The two signatures are then combined, and used to authenticate the validity of the card. If the signature on the card doesn't coincide with the camera's portion the authentication fails.

This way, when you get the camera you get a default password and a camera-specific system signature. Using the default password to verify the initial access you can then change the password. In the event you sell you camera, you either reset the password or provide the new owner with the current one. They can then (within 4-minutes if they want) set a new password.

To bypass or override the system you'd need to have both the camera signature, and the current camera master password. Without both of those things it would be impossible to present verifiable credentials to the firmware.

The only weak-point in a system like this is the software that does the verification. If that can be bypassed then you're all out of luck because where it does the checks on the validity you can simple bypass entirely. However in the case of the RED camera that would be modifying a binary-only firmware image that can't be traced or observed during execution and compiled in non-standard machine code. It would be very difficult to find and you'd stand a pretty good chance of bricking the camera. Also, the RED firmware update process has it's own internal verification to prevent the installation of a damaged image, so you'd also have to get around that to present a modified firmware image that the camera would believe to be valid.

 

[Conrad Hunziker]

Guys-

I do appreciate you guys trying to re-explain to me PAKE and EKE security systems. Unfortunately my response can be summed up in six letters: MITM & RE. Knowing exactly how the key is generated in the software, and knowing the Red key (even if it is camera specific), the user password truly doesnt matter. The guys in 4chan could crack it in a week, the NSA guys (probably) in a day. Producing a collision when the key is not known would take between 2 weeks and 1000 years, depending on the underlying algorithm used, with modern equipment (to say nothing of bot farms). However, if part or most of the key is known it exponentially reduces the amount of time needed. In addition, by analyzing the software, the hacker will know exactly which underlying algorithm was used (SHA1, SHA256, MD5 (lets hope not MD5), etc...), the placement of different identifying markers and even what user passwords would be most effective and which passwords would produce the most collisions. A couple of days work for those not-too inclined.

Now you say, you need to have the Red key! Ah ha, and you would be correct. You would need to have the camera-specific key to crack the user password. A little social engineering anyone?

I have no issue with Red using PAKE as their auth scheme - or really any auth scheme Red chooses. It will work fabulously. But it will only work when THEY keep the algorithm used to generate the SD card in THEIR hands. Again, security is only obtained by limiting your exposure. So by keeping the camera-specific code and the key generating algorithm in their hands, they limit their potential exposure. The hacker would then need to guess at the underlying algorithm, guess at the exact auth scheme used and guess at the placement of identifying markers. All of those exponentially increase the amount of time needed to hack the key. And in addition, since both sides of the key would be controlled by Red (in the camera and behind the website), they could do whatever they want with it - change the algorithm at will - since they control both sides of it. That would provide even more security than what could be done in software.

And really, what exactly are we gaining by doing it in software? All you are gaining is the ability to generate a key in the middle of nowhere with no internet access. However, as I expressed earlier, theres very few places on this planet that are less than 30 minutes from a ethernet cable. Yes the links may be slow, but they work.

Again, we are talking a really small percentage of users who would be affected by having to go to find internet to make their systems work. You would need to meet ALL of the conditions:
- Have not paid attention to any of the warning screens (and not confirmed that you have your SD card ready)
- Have traveled to the far end of the earth and found yourself on top of Everest or under 1000 feet of water. (Heck, even Antarctica has streaming feeds)
- Have used all of your time / boots
- Have misplaced your master SD card or been on a rental & not contacted the owner

At that point, will it really be Reds fault for opening up a security risk and not releasing the SD key generation software? And for those who are on rental, you would need to give them a master or sub-master SD card anyways. So how would you deliver it best if they are out of town? Internet perhaps? You certainly would NOT give them your password, as they would then just unlock it and (potentially) steal it.

I really dont see any benefit to having a software based system. Coupled with the fact that Red will need to code it for at least 2 different OSes, troubleshoot and maintain them, the software version is simply a non-starter. I would much rather have Red spending its time working on the Redcode algorithm, not the security algorithm in multiple OSes.

As a programmer the first thing you know is that once you release a software product, count on it being stolen and hacked. It will happen. Doesnt matter if the software is well protected - the only thing thats is really protecting it is a piece of paper, and we all know how well that does. I know for a fact that my programs have been stolen and hacked, and I have to deal with it and the lost income. But thats a minor annoyance compared to what would happen if the software for generating SD keys was hacked.

Of course, this all assumes this whole complicated mess gets coded to begin with.

 

[Peter Majtan]

Guys-

I do appreciate you guys trying to re-explain to me PAKE and EKE security systems. Unfortunately my response can be summed up in six letters: MITM & RE. Knowing exactly how the key is generated in the software, and knowing the Red key (even if it is camera specific), the user password truly doesnt matter. The guys in 4chan could crack it in a week, the NSA guys (probably) in a day. Producing a collision when the key is not known would take between 2 weeks and 1000 years, depending on the underlying algorithm used, with modern equipment (to say nothing of bot farms). However, if part or most of the key is known it exponentially reduces the amount of time needed. In addition, by analyzing the software, the hacker will know exactly which underlying algorithm was used (SHA1, SHA256, MD5 (lets hope not MD5), etc...), the placement of different identifying markers and even what user passwords would be most effective and which passwords would produce the most collisions. A couple of days work for those not-too inclined.

But You are forgetting two things:

A. The strings would have to match EXACTLY...
B. For each try You will need to format the SD and boot the camera. Unlike PC's - there is no direct comm with the camera to try hacking into in real time. This alone renders it impractical (to be polite).

The camera would only look at the "properly" coded SD card - which I agree someone could crack eventually. But then the camera just compares the strings - digit by digit. So You will HAVE TO crack the users password to get the exact string generated. And once again - for each try You will have to format the SD and boot the camera. Best of luck...

Peter

 

[Frazier Nivens]

Theft Protection

Theft Protection

Yes, please to having Key protection for the camera. Insurance is a must but locking a thief out probably won't stop the thief but will make them very unhappy after they figure out they can't use it.

Planning on upgrading and hope that this is built into EPIC and Scarlet.

Best,
Frazier Nivens

 

[gary adcock]

some reasons for not supporting RED-Key

some reasons for not supporting RED-Key

. And please remember - You do not need to activate this security function, in which case Your Red One will function as usual, just unprotected... So I really don't see why would anyone say NO without specifying valid concern... Peter

Additional code support would need to be written and debugged at multiple levels. This would most likely require additional resources at RED at the code level for this type of measure- are you willing to pay extra for this?

Hardware dongles are a pain in the ass and an SD card dongle is no better and it takes away that slot if needed. What if you order your camera without a SD card? Would it be a RED CF card or something custom?
how would the security be handled on the CF card? with a USB dongle at least it would be difficult to get to the firmware- on a CF card there would need to be something that would allow for secure content without the ability to overwrite - that means a custom CF format card to do something a USB dongle has done for a longer period of time.

So who pays?

How to deal with this issue if a camera goes out without a key or it gets damaged while out on a rental job?



No offense Paul, but I see this an attempt to close the barn after the horses get out. Pro cameras are stolen on a daily basis around the world, and in all honesty it is not the camera that costs money- it is the accessories and glass, so securing the camera becomes secondary with a lens case worth 10x as much.

 

[JanneJansson]

To have securety in a camera is a bad idea.
Just 1000 bugs and extra camera crashed waiting to happen.

 

[Jeff Kilgroe]

B. For each try You will need to format the SD and boot the camera. Unlike PC's - there is no direct comm with the camera to try hacking into in real time. This alone renders it impractical (to be polite).

Sure, if someone wants to go through the brain damage of the SD card and repeatedly booting the camera... But seriously, what keeps a hacker from opening the camera, offloading images of any internal camera FLASH and ROMs, creating their own firmware that circumvents the protection, then loading that onto the camera?

So You will HAVE TO crack the users password to get the exact string generated. And once again - for each try You will have to format the SD and boot the camera. Best of luck...

Think of it like busting into a bank vault... Why go through a time-consuming process of determining how to dial the combination, when you can blast a hole in the wall instead. OK, bad analogy, but you need to think like a hacker.

With the example of your Key protection, all is for not if the hacker downloads firmware from RED, locates the value for remaining boots and changes it to be the maximum value. Then isolates the bit of code that increments the boot count and changes it from a +1 to +0. Then loads their patched firmware. OK, now the boot count never expires on that camera and it never asks for the SD key. Working camera... Or at least until the next firmware update comes out and the hacker will worry about it then.

 

[Gunleik Groven]

I have one securitysystem I am happy with - USB dongles (for software). Just plug-in and start on any computer. But that would be counter-productive in this context...

A pin-code @ startup that could be disabled, would be cool, but I guess, if it is there, insurance will demand that it is used, and thus not something I'd really like to see...

To me, the best solution would be to have a unique identifier in the files, and lock out stolen cameras in the SDK/developing software.

When a camera is stolen, it will remain useable untill the next update, but then be rendered useless. Untill reported back with the owner.

Just my 2c

 

[Jeff Kilgroe]

To me, the best solution would be to have a unique identifier in the files, and lock out stolen cameras in the SDK/developing software.

I kinda suggested that, but on further reflection, I think that makes little sense too. Not every developer of RED supporting tools is going to want to implement camera restrictions. Any hacker who wants to crack RED software to ignore the camera check could easily do so, especially if the functions are already there in the SDK for reference. And even that probably would be more effort than necessary. A simple search and replace of the camera SN or PIN in an R3D file would make it usable again.

Also Stephen Williams brought up a point earlier, after I suggest the post software lock-out. What does this do to existing footage that you still may need to work with? Do we need a special key or password to enable using our old footage from a stolen camera then? What a pain... But do-able for a small shop or individual. But what about larger productions that may have to send that footage to different people for different operations. Now they all have to know how to access it. No, not going to work.

As for the USB dongle. I find them a complete pain in the ass, a waste of time, and an insult to the paying customer. I'm glad to see the recent trend of many software companies moving away from using them. They're too easy to defeat and too costly to implement and support. Unfortunately, the latest trend is the online activation method and it's even worse at times. It just keeps the casual software owner, who probably legitimately bought the software to begin with, from installing on "too many systems". Or at least that is the case until someone with a decent calculator decides to make a key generator. ...I think the Adobe CS4 keygen was available on the net before CS4 retail boxes had shipped to distributors. So what's the point? I have CS4 on my primary workstation and on my macbook pro. If I want to install it on another workstation, I can but have to de-activate it on one of the current systems to activate it there. Or buy another copy. OTOH, the kid down the street downloaded perfect disc images of CS4 master collection and a key generator in less than an hour (gotta love torrents) and already has it installed on every computer he has come into contact with and is whoring himself out on myspace, facebook and elance as a graphic artist of some sort.

Sorry to branch OT.. I'm just saying that I believe copy protection is a waste of resources, and so would theft protection on a camera. Even if it's pretty darn good and would work 60% of the time or better, I don't see how it wouldn't inconvenience the owner. I've had equipment stolen, it's just a fact of life and I'm wiser for it these days, take better care of my stuff. But I don't see a need for theft protection on a RED One, Epic or Scarlet. Does the Sony f23 or f35 have protection? No. What about the Viper? No. And at $18K, the RED One body being stolen is not what concerns me. What about the real expensive stuff like lights, lenses, etc?? We may as well be demanding that Arri put GPS trackers in all the Master primes as most of those lenses will each cost more than a RED One camera body.

 

[Conrad Hunziker]

But You are forgetting two things:

A. The strings would have to match EXACTLY...
B. For each try You will need to format the SD and boot the camera. Unlike PC's - there is no direct comm with the camera to try hacking into in real time. This alone renders it impractical (to be polite).

Ahh - but you are forgetting two things. I dont need to know your password, or even the string. In fact I really dont care about YOUR password. I just need to figure out a collision. By knowing how to generate said keys, and by using it to find all values of a key in advance (trivial to do, at best), I can figure out which passwords produce the most collisions. With that, I simply try those passwords and for each time I try I actually am trying (for example) 50 passwords at once, based on the number of collisions.

In addition, formatting a SD card is not all that hard. In fact, there are USB to SD card thingies out there that will replicate a SD card in a slot, so all I have to do is insert it and try several times. Or just have several SD cards going round robin.

Yes, trying would be time consuming. But with an hour I can try 50 times, and each of those would say be the passwords with (say) 50 collisions. Therefore in an hour Ive tried 2500 passwords.

 

[Dylan Reeve]

Sure, if someone wants to go through the brain damage of the SD card and repeatedly booting the camera... But seriously, what keeps a hacker from opening the camera, offloading images of any internal camera FLASH and ROMs, creating their own firmware that circumvents the protection, then loading that onto the camera?

Hard to know exactly what would be involved, but it could well include demounting soldered components. Also, they'd need to have a development environment to debug, trace and execute the firmware and ROMs - which is more difficult when custom hardware is involved. Yeah, certainly that could probably be done, but the time and effort required would be massive compared to the possible benefit.

Think of it like busting into a bank vault... Why go through a time-consuming process of determining how to dial the combination, when you can blast a hole in the wall instead. OK, bad analogy, but you need to think like a hacker.

The complexity of hacking into a closed hardware system is much much greater than something like the iPhone (where an SDK was available, and direct communication is provided), or a Windows software application (where it can easily be traced and modified.

With the example of your Key protection, all is for not if the hacker downloads firmware from RED, locates the value for remaining boots and changes it to be the maximum value. Then isolates the bit of code that increments the boot count and changes it from a +1 to +0. Then loads their patched firmware. OK, now the boot count never expires on that camera and it never asks for the SD key. Working camera... Or at least until the next firmware update comes out and the hacker will worry about it then.

Yes, or replaced the key verification functions with something that always returns a sucessful result (how most dongle-cracks work for software). It would, however, be very difficult to do that in the RED Firmware as the only place it executes is on the camera, where it's operation can't be observed. Also the camera has measures in place to verify the validity of a firmware image before installing it. Meaning you'd need to modify the image while also ensuring it still passed whatever validity tests were made.

All this is rather academic however. Overall a system that is sufficently strong (ie, very far from trivial to crack) could be implemented in one of a number of ways. However it is not for us to do it, it is up to RED, and they have existing development resources and priorities, and at this stage these suggestions probably don't rate as a footnote on the roadmap.

 

[Dylan Reeve]

Ahh - but you are forgetting two things. I dont need to know your password, or even the string. In fact I really dont care about YOUR password. I just need to figure out a collision. By knowing how to generate said keys, and by using it to find all values of a key in advance (trivial to do, at best), I can figure out which passwords produce the most collisions. With that, I simply try those passwords and for each time I try I actually am trying (for example) 50 passwords at once, based on the number of collisions.

In addition, formatting a SD card is not all that hard. In fact, there are USB to SD card thingies out there that will replicate a SD card in a slot, so all I have to do is insert it and try several times. Or just have several SD cards going round robin.

Yes, trying would be time consuming. But with an hour I can try 50 times, and each of those would say be the passwords with (say) 50 collisions. Therefore in an hour Ive tried 2500 passwords.

I think you're over estimating the simplicity with which something like this might be achieved. In a hardware system where the authentication verification is controlled in a 'black box' like the RED, the ability to make multiple collision attempts is limited. If the card structure is such that only a single auth package will be read, it could take millions or billions of attempts to brute-force your way in.

 

[Gunleik Groven]

Agreed that copy-protection is a PITA, and I haven't subscribed to any of the options...

A unique identifier would be a good idea anyhow, even without the post lockout.

 

[Robert P. Hogue]

Another good idea would be a USB dongle, that can be plugged into the camera every so many starts. An SD card if stolen, can be duplicated - drag and drop files to desktop, and copy to another SD card. The dongle could contain activations for one or multiple cameras. If no dongle is present after so many starts, it asks the unsuspecting user to plug into a computer through a USB or firewire port, and phones home.

 

[JanneJansson]

A better idea is not to waste energy on over-complicated dumb-locks, and focus on just making a cam that shoot beautiful pics

 

[Conrad Hunziker]

I think you're over estimating the simplicity with which something like this might be achieved. In a hardware system where the authentication verification is controlled in a 'black box' like the RED, the ability to make multiple collision attempts is limited. If the card structure is such that only a single auth package will be read, it could take millions or billions of attempts to brute-force your way in.

The point is not if the collision is hard or simple, or the amount of time it takes. The point is that by using client side software you make this risk significantly larger than if you generated the SD keys behind Reds website. If I can RE the software and figure out what auth scheme they are using and even have a copy of the camera-specific key, Im thousands of miles ahead in the race to crack any cameras password. Your right it could take billions of collisions to figure it out. But it could take 2. The chances for any one collision being the right one are exactly the same, and your chances of finding the right one increase with every wrong one you discard. And you can use side channel attacks to help determine how close you are.

By simply putting the SD key generation behind a website you mitigate this significant risk and make cracking any auth scheme orders of magnitude harder to crack.

Another way to put it: Ive got a box in a field 100 yards away from a burglar, and it contains $17,500. I put a lock on it. Do I want to give the burglar half a key and a lockpick, or do I want to blindfold & spin the burglar?