Schneier on Security

Nick P • October 10, 2014 10:22 AM

@ Thoth

Here is my comment describing my polymorphic cipher. I made a variant of it years before in response to a snake oil company’s claims. Then, they adopted a version of it and blended in some extra snake oil. Lol…

Nick P • October 10, 2014 2:05 PM

A preliminary security assessment of DTU’s Double Encryption
(based on patent)

Let’s give it a fair review. Here is the patent application from DTU. It’s written in legalease like many patents so this is a preliminary review based on little information. Like Clive says, it also seems to have gone through Google Translate. Made abstract and many claims gibberish. Fortunately, the summary section does a great job explaining what it is:

“In accordance with this aspect of the invention, it is not necessary for the receiving apparatus to have, pre-installed, a suitable decryption application to match the encryption technique. It is not necessary for the recipient of the data to negotiate which encryption technique has been used, and there is no need for communication between the sender and receiver to identify the technique which will be used. The requirements for decrypting the data are entirely self- contained within the decryption program and there is no need for the permanent installation of a decryption application or an application including a decryption routine on the receiving apparatus. Of course, the decryption routine may need access to standard features of the operating system which will be running on the receiving apparatus. One of the initial steps may be to specify the operating system of the target receiving apparatus. A programming language for the program will be chosen that is compatible with the target operating system. A first encryption technique may be selected automatically without user selection. The sender has access to a plurality of encryption techniques and one of these is selected for a particular message. This could be a matter of personal choice by the sender, or could be in accordance with a set rota, or could be on a random basis. If the sender is not responsible for the choice of encryption technique, that task being left instead to software serving as an encryption management system, then the arrangement may be such that not even the sender knows which encryption technique has been used for any particular message. If an attacker intercepts a message transmitted in accordance with the invention, there is additional secrecy because the attacker must attempt to identify the decryption routine. Not until that has been done, could an attacker attempt to break the encryption technique. If the program is in the form of executable code, then there is the additional obstacle for an attacker that the executable code must be de-compiled into a higher language that can be understood, before attempting to identify the decryption routine. ”

The system picks the initial cipher based on the key to create the starting session. This appears to be an obfuscated version of a TLS-like protocol. If it uses TLS, it’s equivalent in security so long as algorithms and implementation are strong. If not TLS, protocol design & implementation must be solid too. The author adds an additional obfuscation layer by next generating a custom cryptosystem based on existing algorithms, then sends that to the recipient. So long as only safe interactions & constructions are allowed, this has benefit over relying on one algorithm. The cryptosystem can also be isolated from the application using it in such as way that even the app doesn’t know the specifics, although not mandated. Then the author makes the actual security claim: the attacker must identify the custom-generated decryption routine for intercepted messages before cracking it. Author claims this requires decompilation and reverse engineering*.

• It mostly sounded good until he wrote that. From the descriptions, the key drives the whole process by algorithm, starting with one crypto algorithm. Getting the key or cracking the first [single algorithm] lets you decrypt the first session. That gives you the custom program sent over it. Then you use the same custom program to decrypt the rest of the traffic. So, whole scheme security is bounded at the first cipher used, the RNG, or system integrity. That means the security claim of the major innovation is already false. Although, the first part still has potential. Let’s proceed.

Risk Assessment

1. They have 100 algorithms available. Any that becomes initial algorithm must be strong. I don’t know 100 proven-strong algorithms, so this already concerns me. More on this in 3.
2. The initial protocol must be strong against all of the attacks on protocol design and implementation. This includes covert/side channels. Here be dragons.
3. The encryption algorithm generator must be free of defects and only produce safe constructions. As in, certain algorithms combined actually weaken security. These must either (a) not be available or (b) detected, then automatically remedied in a standardized way. This is a risk as the author just references all kinds of tricks for making variants of block and stream ciphers. Any variant might strengthen or weaken it.
4. Per the patent, No 3 must be true for numerous languages on numerous OS API’s and interactions with them.

5. The receiver must verify the incoming code to be safe to execute. Essentially, this scheme runs off foreign code and has the security issues (eg bytecode verification, sandboxing) associated with that.

6. The code itself should have builtin protections against malicious data in case the sending machine gets compromised mid-session & tries to use custom routine to break integrity of receiver.

7. The generated code must be free of covert channels that leak plaintext or key material.

8. One must ensure the compiler doesn’t optimize away the steps that wipe the keys or generated programs from memory.

9. The RNG must be a TRNG or CRNG with good seeding. Patent mentions PRNG. I really hope that was a bad translation as PRNG’s have no business making keys.

Evaluation

If algorithms and protocols are solid, this does increase work of attacker if first algorithm is unbroken. But, if that’s true, then you still get most of the benefit if you just use that one algorithm. So the rest is largely unnecessary. This scheme is a failure before the session even starts. An improvement would be to have both parties generate a custom encryption program immediately from the shared secret, which is never distributed. This cancels out the reduction of security above by overdependence on one cipher and places your trust in key exchange, which is already trusted here.

The bigger issue is trusting foreign code. If you don’t have to, JUST DON’T! It’s a whole field of research on how to do that so it’s a huge risk increase. Plus, the best offerings in higher assurance field rely on static code. That includes secure hardware, transformations, and static analysis. A regular crypto system can be (has been) assured with these schemes. This one can’t: you’d have to re-run the verification process during every session. Who wants to put money down that feature will be in the final product? Not me.

Note: So far it’s a combo of a polymorphic cipher, a JIT, and a variant of the applet/Javascript model.

Performance is another issue. If they’re using the strongest algorithms, there’s a cost to setting them up and using them. Then, they have to compile a crypto system. Then they have to use bandwidth and time distributing that. A static polymorphic system has an initial setup cost, then that’s it. Less time creating the session, negotiating things, transferring things, compiling things, etc. This cryptosystem is horrible on resources compared to static, simpler polyciphers.

Comparison to my own prior art. My polymorphic cipher used 1-3 algorithms in counter mode on a data stream. The choice of algorithms, their keys/nonces, the counter value, and initial iteration count on each counter were derived from the key. That was either a huge, PSK or a hash-based generation of material from a master secret. The algorithm only used the strongest known algorithms in a safe mode and construction. If a one algorithm solution (comparable to D.E. patent), it’s performance impact is the setup cost to some crypto primitives with much of it saying in cache. There is no requirement to trust foreign code or generate/distribute code. Also, substantially less effort reviewing new code, side channels, etc as it’s a simple combination of pre-evaluated components.

Conclusion

This cryptosystem is a bad idea. It combines a nice obfuscation (key-driven cipher selection) with a highly risky “JIT for cryptosystems” concept and relatively horrible efficiency. They’d be better off just getting keys to select from strongest algorithms or a combination of them. Of course, then it wouldn’t be patentable because many of us have designed and published such schemes before. I advise users they’re better off using a simpler, faster, data-driven, polycipher scheme instead of this risky, slower, code-driven scheme.

And remember that your solving the lowest risk part of security: attackers hit the endpoint and implementations often, rarely the crypto algorithms. They’ll just hit you with a code injection, then bypass your crypto. So, the assurances provided by these schemes are false unless they’re running on a system that can’t be compromised or they plus GUI are separated from such a system. The mechanisms used must be highly assured to even stop non-goverment, sophisticated malware. The product will likely run on low assurance systems, so it has little to no benefit over field-proven crypto.

Even if it met its claims in practice, they’d be conning you if they told you that you needed it or it would protect your communications. Just like most of “security” industry’s bogus claims. We need strong endpoint security, not more session encryption.

Nick P • October 10, 2014 7:03 PM

@ Shannon

That’s a decent point to keep in mind in a lot of online forums (esp Slashdot). Most of us regular commenters are fine with patents so long as they’re done for novel stuff and not predatory. My own critique with this patent application is that little of it is novel. The part that is has little security value, so my critique is there is on utility rather than patent eligibility.

@ Daniel

There’s nothing wrong with the obfuscation strategy for reducing opponents’ effectiveness. I use it extensively. The problem is how it is being applied. So, let’s look at the nature of black hats and TLA’s. They mostly dig through the binaries and source to find implementation flaws. Major TLA’s regularly find 0-days in common software, use them to take over the machine, and directly have plaintext. They also look for configuration errors, fallback attacks on protocols, firmware issues, peripheral attacks, physical implants, etc. Lots of stuff to work on to keep communications private in combination with encryption.

The thing is, this is a solution in search of a problem. It’s been a while since the choice of symmetric encryption algorithm doomed a system. I believe it was DES with keys that were too small. The 3DES solution appeared and solved that problem. Over time, we continued to get stronger and stronger algorithms. A few attackers used implementation or side channel attacks on the algorithm, which were remedied. The vast majority 99.999%+ bypassed the encryption entirely with endpoint, network, protocol and application level attacks. All the groups capable of potentially beating a crypto algorithm focus on that other stuff the most because it’s easier.

There might eventually be an attack on the strong algorithms. It’s understandable that people with long-term protection needs might do a polycipher with a rotating set of algorithms or a cascade of them. This can be done with a few, efficient algorithms. Pre-installed. Adding the risk and inefficiencies of foreign, JIT’d, variants of algorithms to further obfuscate something nobody even has a theoretical attack on just isn’t justifiable. Those resources could be spent on one of the area that opponents are actually attacking.

Focusing on this stuff is the classic security problem: replacing an unpicked, strong lock on the front door with a stronger lock while the windows and backdoor are wide open. Better to lock down those windows and backdoor.

Nick P • October 10, 2014 8:25 PM

@ Chris Abbott

It’s built into the key exchange that I’m aware of. That’s how most polyciphers, including mine, work. The key exchange problem remains. One critique I keep having is people going all out on symmetric cipher strength while using a regular asymmetric key exchange. Obvious issue: the public key algorithms are more likely to be broken than the symmetric. They get weaker every year with an impending “quantum apocalypse” on top of that.

The best place for cryptographers to put their effort in, other than cryptanalysis or efficiency improvements, is currently asymmetric and other crypto used for exchanges and signatures. These are most at risk. A massive effort by the cryptographic community should be put into place to do for them what’s been doing in AES, eSTREAM, SHA-3, etc competitions. We need the replacement protocols with assurances ready before the current ones get cracked.

The symmetric algorithms are fine & basic polyciphers/obfuscations can make up for any weaknesses. This is evidenced by the leaks showing NSA has to bypass or subvert standard ciphers instead of crack them.