Schneier on Security

Clive Robinson • February 3, 2017 12:04 PM

@ Hello,

Backdoors scale well, have a minimal technological cost, and are ultimately certain (the other person’s main option is to avoid the technology that is backdoored).

A couple of things to note,

1, This is a false argument, as it’s easily disproved.

2, You’ve not been around this blog much as we’ve discussed the work around a few times, fairly recently.

The point is backdoors are only effective against the general population not those who can read and think a little and put things into practice. Thus the slightly smarter criminals and other undesirables will not be effected by back doors.

Thus they fail the first hurdle of their stated aim, and as I can not believe the national signals agencies and IC are not aware of this as are the seniors in the LEOs. So the question becomes “Why do they want to surveill the generak population so baddly, and store it indefinitely?”[1].

[1] The reason I say indefinitely is because of a little loop hole in the regulations/legislation. They are allowed to keep encrypted traffic indefinitely but not plaintext which is time limited. We know that they have been able to get SSL keys by various means. Thus if they store both the encrypted network traffic and the key they can keep it indefinitely and only have a time limit on when it becomes plaintext that has been “read” sufficiently to recognise it as plaintext…

Clive Robinson • February 3, 2017 10:49 PM

@ Ross Snider,

Having buil[t] backdoors (not for government) I can testify that they have all been cheap, easy and effective.

Yes, it’s something I’ve done myself and mentioned it here quite a while ago along with sufficient information for someone to do the same.

My reason was a petty one, in that I wanted to make a point about just how usless a “code review process” was against insider attacks. Especially when the CRP was done by those who were not the brightest and best coders in the organisation.

Essentialy I put a slightly modified version of what we would now call a “NOBUS backdoor” using kleptography into a BBS-RBG by making one of the primes easily deducible. I then used the pq pair as a Public Key certificate, that I kept hidden in the heap by using a fairly well known and published fault in malloc. The NOBUS backdoor had also been published in a book by Adam Young and Moti Yung back in 2004 called “Malicious Cryptography: Exposing Cryptovirology” which pretty much describes the usefulness of whats in the book[1].

Adam Young got a bit dishartened about the Cryptovirology side due to critisism and thus went on to look at what they named “kleptography”. Anyway read Moti Yung talking about it,

http://privacy-pc.com/articles/moti-yung-and-adam-young-on-kleptography-and-cryptovirology-5-skeptical-experts-and-smart-attackers.html

Put simply the problem with Public Key systems is that is way way to much redundancy. And there are quite easy ways to exploit the redundancy to make a NOBUS backdoor.

The thing is that whilst you can do as I did hide it in plain sight in the source code and get it through a CRP with a couple of tricks it’s presence can be easily spotted in use if you do not use it correctly, and this is where people can go wrong and knowledge of the NOBUS backdoor leaks out.

That is you need a way to hide the information you are leaking via the NOBUS backdoor in the expected traffic. To do this you need redundancy you can exploit in the sent cryptotext. Finding “easy redundancy” of this sort is “not easy” it’s actually a not much thought about “academically” research area in it’s own right.

I cheated for my NOBUS backdoor and used a stream cipher (ARC4) with the addition that it “apparently” randomly encrypted the “normally zero eighth bit in a byte holding seven bit ASCII”. Using the faux excuse that this was “known plain text” that could be exploited by an attacker. Which you can get past managment and the like by demonstrating such an attack on a LFSR based stream cipher[2].

To make it work as a proper NOBUS backdoor, what you need in essence is a redundancy that is transparent through the encryption process. Something that is generaly designed out in encryption algorithms.

Thus one way is to find covert channels in the implementation such as “timing jitter”. However if you have access to the source code either directly or indirectly by reverse engineering the code doing the timing jitter can be very hard to make both hard to find and reliable.

It’s this covert side channel aspect of a NOBUS backdoor that is generaly assumed to be a hard problem and the academic research into it is slim at best.

One reason for this is one of the “Secret TEMPEST” techniques. Unless you design a system to stop it, most systems are transparent to time based covert channels due to “efficiency”. If however you are aware of this “oh so secret” technique then designing it out by either “reclocking” or “store then forward” is relatively trivial.

That is it’s assumed that covert side channels are at best “fragile”. But this is an “assumption” it may not be true, because as far as an academic paper search goes it appears nobody has proved if the assumption is valid or not.

What we do know is that time based covert side channels are very difficult to see, if you use say Spread Spectrum techniques to modulate the time based channel. That is you employ one or more “Low Probability of Intercept” (LPI) techniques that were at one time popular in military communications systems to “code the channel”.

The covert communications people have since moved on to MIMO LPI techniques. What I’ve not seen is any “public” research as to the applicability of such techniques to making side channels not just covert but robust to existing anti-TEMPEST techniques. My own thoughts on the matter is that it will prove to be promising …

[1] There is a Cryptovirology web site,

http://www.cryptovirology.com/

[2] There is a good reason why we do not use Linear Feedback Shift Registers as Key Stream generators, they are way to easy to predict the next bit on previous bits. In text books you get told that that there is a known attack if you can get a length of key stream bits atleast twice the length of the shift register. Many people make the mistake of thinking that it’s adjacent bits you need. That is you often don’t get told that it’s the number of bits that is important not that they all be adjacent to each other. There is a not so well known issue with LFSRs that if you sample the bits at regular intervals you can use those to get the original LFSR output. Thus you can make a software demonstration of a working attack against byte wide seven bit ASCII you can scare people with. The point you hide from managment is that it’s a weakness of the LFSR that such plaintext patterns can be exploited, and that the issue should not exist with CS-PRBG stream generators.

Clive Robinson • February 5, 2017 1:54 PM

@ Steve,

At what point do we say there’s no difference between the two?

From what point of view?

Bearing in mind technology is agnostic to use, “backdoor” is more a statment of a human not technical view point and thus the directing/controling minds intent.

Thus a “backdoor” is very much an intentional choice, where as a technical exploit of a failure in design is not.

Thus arguably they are never going to be the same due to the intentional / unintentional devide.

However this brings up the more practical question of how to differentiate between an unintentional attack vector and an intentional flaw made to look like like an unintentional attack vector.

Obviously there is no doubt with a legislative backdoor as it’s mandated, but a covert backdoor can be perhaps recognised from it’s usage. Because the intent of a backdoor is not just to make Communications traffic available but all User Data available. Thus communications traffic would logically be a subset of all user data thus simple instrumentation of communications links would show a size disparity, that could be seen.

It’s why the likes of Microsoft Win10 and Office364 are pure poison from a user perspective. Because they like Google and Apple do almost whatever they can to force all user data into communications traffic or give the ability to hide it under the weight of “telemetry data” which has sufficient redundancy to have very many covert channels hidden.