Schneier on Security

Clive Robinson • December 7, 2024 12:54 PM

@ ResearcherZero,

With regards FSB it looks like we have the same security item but from different reports.

As far as I can tell, the FSB are still acting “More boots than brains” and it’s why we got to hear about just a little more that is going on toward the East of Europe.

From the news it would appear things are going on in the MidEast and the kinetic support “The English Dentist” was getting has like morning mist either evaporated or gone to ground.

Then there is the alleged use of TikTok by several thousand mist like beings or ghosts in Romania but more likely from the same place that “The English Dentist” got his support,

https://www.bbc.co.uk/news/articles/cvg6l06ldpqo

There are clear warnings being given that the Romanian people need to be mindful of this centuries history with Belarus and Ukraine and kinetic and other “supportive action” from the East.

Clive Robinson • December 13, 2024 12:12 AM

@ Winter, ALL,

With regards,

“I think we should not assume this advice extends to other Americans.”

Or others that are not Americans, as it was in effect,

“The truth acknowledged under duress by the FBI, from their usual lies and nonsense since before the 1990’s and Crypto Wars One.”

So maybe we should thank not just the Western Agencies that eventually pushed for the truth, but also in a way the Foreign National Powers(s) that put the pressure on those agencies.

After all you and I as well as several others who read here can and did work out by simple logic that what ever silly name you gave these unwarranted access methods they would as history almost always shows

“Be abused, not just by those that can get legislated access, but also by those who should not get any access at any time.”

But we should also consider just how good or in reality bad is the advice “use E2EE”?

The problem now is that if E2EE becomes the norm as I suspect it will. Things will change and mandated weaknesses to be exploited will become actual weaknesses of poor design that get exploited.

There is as I’ve pointed out over the years the issue that,

No current consumer device is secure as a system

Mainly for two reasons,

Firstly because the security end point is before the communications end point and this makes an “end run” or “reach around” attack not just plausible but probable (and we know already in use).

Secondly E2EE always has “Key Material”(KeyMat) issues in oh so many respects.

An attacker does not need to break the encryption if they can,

1, Break the random generator.
2, Break the next key selection algorithm.
3, Gain access to the root “shared secrets” in some way.

We know the NSA/GCHQ have broken random generators if for no other reason the start up entropy in what are in effect embedded devices is at best minimal[1].

Such “E2EE” Key generation algorithms are an issue always, as they have to maintain state at both ends of the communications link, without this being in any way available or predictable to an attacker and this is actually quite a hard issue to design correctly.

The simple “20,000ft view” way mostly envisaged is to use around twice the entropy and a block cipher of sufficient security, with part or all of the entropy used to set a counter that is then pushed through what is hoped to be a “One Way Function”(OWF)… But it’s a little like a recipe for making food that says “chuck it in a bowl and serve”, it might work –probably badly– for a salad but for something baked, not a chance.

Which raises the issue that OWF’s are for various reasons “an assumption” and we know way to little currently to “get the balance” or ratios in such algorithms.

But there is also the secondary issue of even if the OWF gives the level of security required, it fails if the “shared” state or it’s starting value can be found by basic knowledge of “the system” production process and the equivalent of a short run of “brut force searching”.

Thus more sophisticated methods are needed, but the result is always that for each and every E2EE connection/communications path to be used the “state” that is the effective “Root of trust” entropy for that path needs to be stored in some way on both “Security End Point” Devices and this can quickly become a lot of vulnerable storage. Thus there needs to be the equivalent of a “Hardware Security Module”(HSM) on both end points and a secure design process for the device (that let’s face it is not going to happen). For instance we already know those manufacturers of CPU’s with supposed “security enclaves” have, lets just say found the task of making them secure more difficult than they dare admit to…

Worse though is “Users are Humans” with all the failings that entails. At the very least is the desire to “back up user data” to “keep them happy” in case the user looses or breaks their device. Which means each and every one of those “Roots of Trust” need to be “Stored Off Device”. So in effect “made available” to 3rd Party attackers via another probably easier path of attack without either the 1st or 2nd parties communicating knowing it.

It’s just one of the reasons I advocate for entirely separate devices for the “Security End Point” and the “Communications End Point”.

Life as they say is “never easy” especially with humans involved…

[1] This is something I’ve pointed out for way more than a decade here and longer else where. Back in the early 1990’s I wrote about this significant issue for an employer who had design engineers in Korea that “assumed” quite incorrectly that “silicon starts up randomly”. They only needed 20bit of entropy for producing an “Over the Air ID” on the production line, but what they found way to late, is that they were not getting even 7bits at the tails…