Schneier on Security

Clive Robinson • October 10, 2019 1:55 PM

@ Bruce,

I just noticed that the article is from 2018.

Sounds like your “reading pile” needs not just a spring clean but a pruning as well 😉

That said, I’ve a backlog of something like sixty PDFs of papers I need to do more than skim read 🙁

Clive Robinson • October 10, 2019 2:04 PM

@ me,

But you can’t associate any profile with it, you can only know that someone visited both places

That is a dangerous assumption on your behalf.

All I said is that they are putting out signals, not what the signals were or what authentication or other identification tags that might be contained in them.

As far as I was concerned seeing a smart phone push out ISM band signals –on a cheap SDR receiver– when they should not have been was more than sufficient for me to say it’s not behaving in a trustworthy fasion.

I did not need to test further to see what the signaling modulation format was, or work out what data it contained it was just sufficient to know it was “out of the box” not doing what it was supposed to do.

It was a more efficient use of my scant resources to move on to a different smart phone and test that instead.

Clive Robinson • October 10, 2019 3:06 PM

@ Anon838,

And what phones would that be?

Well what started it all was somebodies Apple phone in the RF Lab, I’d been asked to look into as a favour. The phone was causing problems during testing of a high gain receiver front end for the top end of the 2.3GHz – 2.45GHz band used for satellite communications (and is just below and overlapped by the 2.4-2.5 ISM band).

Other phones were then quickly tested, some of which that had issues were Chinese branded (ZTE manufacture) and also some “badge labled” Chinese low cost phones sold in small retail outlets. There was correlation with the versions of software used on the Chinese phones, that suggests the problem came from “up stream” of the actual hardware manufacturer. As not all phones from any given manufacturer exhibited the problem, it is more likely to be a bug in the User Interface software rather than some kind of implant or backdoor. But that’s a hunch from a limited sample size rather than from a larger size to establish the actual bug.

This was because the tests were far from exhaustive as it was mainly phones on loan from staff at the lab, and a few that had be purchased for an earlier project. It was sufficient though to have a new rule of “No phones in the RF Lab or surrounding area” rather than the older “turn them off please” request.

The fact that there is such a problem points at there being a failure in software development test. The cost of tracking it down is not one that has any ROI on it for the lab, or I suspect any other commercial organisation.

Thus if someone else want’s to carry out extensive tests and pay for the time required to do it then they can put their hand in their pocket or set up their own test facility etc.

Whilst the cost involved with obtaining the equipment to carry out the basic tests is quite minimal –laptop, SDR receiver, E field probe, desktop TEM cell, and LISN– the labour cost is not. Further to take the tests to the level where you could publish the sort of results people want, requires considerably more skilled personnel at comensurately higher fees (unless they are doctoral students in a Uni lab).

Pays your money makes your choice.