Encryption is NOT the panacea IBM is telling you it is

You may recall that I have said many times that encryption is pointless because the protected asset eventually has to be decrypted somewhere and the hacker can simply get the asset from the decrypted location?  Below is an article I wrote based on my previous discussions on this subject…

The first group of “cybersecurity experts”

There are two kinds of “cybersecurity” experts. One kind, as represented by IBM, CA, Symantec, Intel/McAfee, and FireEye, knows very little about the actual cybersecurity problem domain but a whole lot about extorting money from captive customers and the ignorant public in the name of “cybersecurity” without ever solving it (because solving the true underlying cybersecurity problem would make their lucrative business model also go away). Their cybersecurity failures are splashed all over the headlines these days, but they’ve managed to keep their names and associations with the crimes out of the press and off the websites though onerous contract stipulations with their customers forbidding their customers/victims from revealing the vendors’ identities and involvement in breaches.

The process this first group of guys engage in is known to industry professionals as “churning”, and relies primarily on ancient Container-Related Asset Protection (AKA, “CRAP”) technologies Band-Aided over with, or sometimes bundled with, pop-culture-inspired fads as apps. These technologies tend to aggregate ever-larger groups of otherwise-unprotected digital assets (files) into silos or containers (you would recognize these silos and containers as browsers, operating systems, file systems, servers, server farms, or the cloud) and protect them while stationary and in those silos/containers (as though that means anything in an increasingly-mobile world). In so doing, they make the rewards to hackers for breaching those silos/containers ever more profitable, worthwhile, and attractive, to the extent that now state actors (Russia, China, the Ukraine and other Baltic states, North Korea, India, Iran, Israel, the U.S, Europe, and various third-world dictatorships, among many others) with virtually unlimited resources (especially in comparison to the average business or intellectual property owner) are actively and aggressively involved in hacking. The more rewards (digital assets) there are for breaching a container or silo, the more motivation there is to hack the container in the first place. And oddly enough, the more resources you devote to “protecting” a container or silo, the more you advertise not only where the important things are stored (these CRAP technologies all have signatures and attack surfaces known to hackers), but how valuable you consider the digital assets stored there to be (like placing a sign over your wall safe that says “all the cash is stored here”).

A classic and unwinnable Chinese finger puzzle if there ever was one – for more information on CRAP technologies and industry churning, see our companion articles entitled “David Versus the Greediest Goliath“, “IBM, CA, Symantec, McAfee: The Car-Jackers of Cybersecurity“, and “AMULET™ intellectual property protection versus Container-Related Asset Protection (CRAP)“.

The second group knows the actual problem domain

The second group of cybersecurity experts knows the cybersecurity problem domain well from the standpoint of solving for it (as opposed to merely profiting from it) – those are the people who may have been at one time hackers themselves, or who are intimately familiar with the failings of CRAP technologies, or who have for decades seen the flaws in how CRAP technology defects are amplified by their implementations in actual installations in many dozens of industries across the country (Certitude Digital staff represent all of those people well). Certitude Digital and its principals are proudly founding and sustaining members of that second group.

Where the video comes in

You will note, if you’ve read some of our materials or are familiar with our patents and technologies, that we have said many times that encryption is pointless in and of itself in direct application to cybersecurity because the protected asset eventually has to be decrypted somewhere – and the hacker can simply get the asset from the decrypted location (locations which, in technologies that aren’t Certitude Digital’s, are well known to hackers). Some people won’t read the book and have to wait for the movie to come out, so here it is in a form everyone should be able to comprehend (smile):

[first video link]

[second video link]

Car thieves have figured out that encryption is its own worst enemy (it forces decryption to a known, specific location), and have implemented the same workaround as desktop computer hackers to solve encrypted car key fobs. In the case of car key fobs, all of the work is done in the same computer (the one on the vehicle), and the digital assets are already there, also on the vehicle (as pathways to door looks and the ignition keys). That is, the “known location” of the decrypted result happens to be the vehicle itself – how convenient!

What’s going on in both videos is this (same technique, two different makes of cars, simplified for a non-technical audience): Most car key fobs work on the basis that the car computer and the key fob each have a separate understanding as to how to calculate the same encryption key from a combination of the unique identifier of the key fob and the time-stamp taken at the moment a key fob signal is sent from/delivered to the car’s computer. When a key fob button is pressed, say “Open door” (which is what the thieves are doing the first time one waves the relay box in front of the garage door), the key fob makes a connection with the car computer, and the two components agree what time it is at that instant. Then, based on that time, they each independently calculate what the encryption key should be from the unique key fob (already known to the key fob, and which key fob is assigned to the vehicle is set in the vehicle computer by the manufacturer) and the time-stamp (looked up in a table of “rolling codes” stored in each device based on the time in milliseconds). The “Open door” command is encrypted using the calculated encryption key, and sent to the car’s computer. The vehicle’s computer then, using its time-stamp of the original key fob connection time and its own rolling codes table, reverses the process (determines a key from the assigned key fob ID and connection time-stamp, and decrypts the message to get the command code).

The most interesting thing to note here is that the conversations between key fob and car computer work in both directions – the key fob can initiate the conversation, or the car computer can initiate the conversation (when you walk up to a car with the key fob in your pocket and pull on a door handle, the car computer initiates the “Open door” command, in effect asking the key fob to send it that “Open door” command, which it will do if within range of the vehicle).

Despite what the CRAP purveyors are telling you about how their “protection” comes from the difficulty of cracking encryption, the opposite is actually true. What the thieves above are doing is merely making it possible for that communication to happen, rather than interfering with it or trying to decode it (just as hackers do on a desktop computer – let the process play out, then simply take the results). In other words, the method and sophistication of whatever encryption is used has become irrelevant. The relay box held by the first thief in front of the car door handle merely captures and amplifies the request from the door handle (via the car’s computer) back to the set of keys the thieves know are sitting somewhere in the owner’s home, and the relay box waved in front of the garage door by the second thief captures and amplifies the response from the owner’s keys and forwards it to the car’s computer.

That opens the right rear door of the vehicle. The thieves use exactly the same process (initiated by the vehicle’s starter button) to start the car (which is why you see the second thief waving his relay box in front of the garage door a second time, and then run back to his own vehicle once the stolen vehicle has started).

As you can see, the workaround to any type of encryption is actually to make it possible to complete its work (in this case, actually enhance it), rather than try to oppose it or modify the encryption/decryption in any way. Then simply take the results after decryption and go your merry way (in the case of the video, literally).

Now perhaps you are starting to understand what it is we have been trying to tell the world about the senselessness of relying on encryption? Duh, even car thieves are smart enough to work around it. It’s exactly like the scimitar-wielding Arab who religiously polishes his swords and mounts an intimidating display of shock and awe in the bazaar in the Indiana Jones movie, merely to get his silly @ss shot dead.

Yes, encryption has its place in cybersecurity, but not in the way used by traditional cybersecurity tools. They are using it backwards (see our explanation of fail safety at our Certitude Digital website).

But for the record, we are in the cybersecurity business, not the “I told you so” business (although the “I told you so” business is much easier and more fun, grin). We provide solutions to society’s problems. To that end, like Certitude Digital AMULET™s themselves, the solution to the car thief problem shown above is very simple and effective – whenever you are away from your vehicle for any reason, make sure the key fob is encased in an all-metal container from which signals cannot escape (I am thinking that Certitude Digital needs to offer these little containers, emblazoned with the AMULET™ shield, as give-away SWAG).

Which will, of course, be unnecessary once inexpensive, efficient, and effective Certitude Digital technology is embedded into future automobile firmware and software, and eventually into every other intelligent device on planet Earth.


F. Scott Deaver



2017-11-28T21:54:28+00:00November 28th, 2017|