Our Cellphones Aren't Safe
nytimes.com
nytimes.com
In the history of the industry no mass-market computing platform has been safer than the flagship hardware/software platforms from Apple and Google --- on no platform does an exploitable vulnerability cost more to obtain, and no platforms have ever been more capable of establishing secure channels between themselves.
SS7 is insecure. But operational practices at both the carriers and inside governments rely on those insecurities to get jobs done, and some of those jobs are important and enjoy wide support. Anything we do to shore up the security of SS7 will, almost necessarily, include compromises most of us here will find hateful, and we'll be stuck with those compromises for another generation.
Rather than "fixing the potholes" in GSM and SS7, we could instead accept that the cell signaling layer is insecure, and route around those weaknesses with application code that can establish end-to-end secure channels accountable only to their users. That's pretty close to what Apple has already done with SMS text messaging, which opportunistically upgrades to Apple's secure iMessage protocol. We can do even better than that!
That's what we've done with the Internet, where this approach is called "the end to end argument in system design". It worked there and will work just as well for telephony.
The problem with the potholes such as silent SMS are not that they exist, it's that baseband manufacturers have demonstrated unwillingness to address them. Alongside other readily addressable things such as IMSI catchers.
It's cool we made the application processor secure, but it's pretty pointless when the 5G chip is in fact a hostile implant.
What's the status for Android devices?
Is it true, as DCKing says, that the baseband radio doesn't have access in "common chipsets used in Android phones"?
"To protect the device from vulnerabilities in network processor firmware, network interfaces including Wi-Fi and baseband have limited access to application processor memory. When USB or SDIO is used to interface with the network processor, the network processor can’t initiate Direct Memory Access (DMA) transactions to the application processor. When PCIe is used, each network processor is on its own isolated PCIe bus. An IOMMU on each PCIe bus limits the network processor’s DMA access to pages of memory containing its network packets or control structures."
It may have been true on older phones with simpler system architectures but you're really going to need some new evidence to show the meme still holds true.
How do you figure? When Apple or Google say 'baseband is constrained from accessing OS memory in the following ways', these aren't unverifiable claims. People would be doing demos at conferences showing malicious basebands thieving your private catpictures.
Uhh no, that’s not how security assurances work.
Of course that does not automatically means that those systems do exists like fictional echelon project but potentially power is there and know tech also...
[Citation really needed]
Not exactly a citation for the exact claim, but several people in this thread make the assertion that Qualcomm processors have some kind of location tracking service running on them, running under a parallel OS:
https://news.ycombinator.com/item?id=17081684
I think that's pretty close. The baseband processor is just one of the many hidden nooks that can run privacy-invading/security-breaking code outside of user view or control.
Also, I think it stands to reason that the baseband processor has everything it needs to at least relay a rough location: the list of in-range towers ~= user location, and it has full control of a channel to relay that information.
With the baseband and application processors being logically separate, strengthening the isolation between them is straightforward.
For starters, you can use a phone with a discrete baseband chipset, like the Samsung Exynos lines.
Or use a Wifi-only application computing device with a separate not-always-on Mifi for a data connection.
If you want to be more paranoid, use an application processor with an Atheros chip and MMU, or a third device as a protocol converter to translates Wifi to RS-232.
But the real point is that with IP-based protocols and Free software, you can unilaterally do any of the above without requiring your friends to also do so in lock step.
This little fella hangs an lte modem off a qca wisoc via usb (on a mini pcie slot). The stock modem is a little spotty, but is trivially replaced.
They ship with a fork of OpenWRT, or you can use an official OpenWRT build on it. When I find a few free hours, I'm hoping to put together a set of Buildroot configs as well.
Trump, on the other hand, does use an iPhone but doesn't have it checked by security experts as often as his aides would like [2]
[1] https://www.digitaltrends.com/mobile/obama-ditches-blackberr...
[2] https://www.politico.com/story/2018/05/21/trump-phone-securi...
Apple/Google have made great progress in several areas, but there are just pieces of the puzzle we entrust the carriers with:
General Location Information: By the nature of the way cellular networks work, they require all times the device is powered the relative location of the device. There are lots of rules and carrier preferences around this, but when the radio is active, the cellular network needs to know which are the closest towers, and when the radio is inactive, a wider location (think a postal/zip code).
I think most people would reasonably consider leaking this information or allowing it to be public unreasonable.
Specific Location Information: So I'm not totally sure about this one, since I unfortunately never took the opportunity to test it. There exists a diameter API for e911 services, that allows requesting the GPS coordinates of a device. I never tested this out, to see if the device would notify if this API was used, or whether it was only functional form within a 911 call.
So take it with a grain of salt, but embedded within this might be the possibility to continually request specific GPS coordinates of a device.
Denial of Service: A large issue with many of these weaknesses, is it can lead to targeted denial of service. So if I have access to the diameter network, I can send routing updates to a location where you aren't, and continually deny you access to the network.
The device might be secure, but if you can't use it, it's still a problem. This wouldn't require much sophistication, probably on a similar level to say running a ddos attack against a website.
Inflated Billing: Another side effect, I can target you and generate inflated bills, by indicating you are roaming on an expensive network. When I left, I believe the most expensive roaming location was still $65 CDN/MB. Try and deal with a carrier explaining that you can't possibly be in Canada and Africa at the same time.
Detectability: These problems can be hard to detect, if you suspect fraud on you're account due to denial of service or inflated billing, there are only a select few people at the carrier that can find these problems. Diameter protocol also has a specific weakness, in that requests are routed by destination network, but answers are routed back along the path the request took, and may cross 3-4 companies networks. So even if you try and implement source based policy, it's trivially easy to spoof the source when implementing these types of attacks.
Sim Updates: I'm not totally familiar with this part of the architecture, but if your able to spoof the device into connecting to a rogue network, you may be able to do more nefarious things than just route or block the user plane traffic. You may actually be able to send sim updates, that could brick the device or maybe even run programs on the sim card. Don't hold me to this though, I'm pretty far removed from this part of the spec.
I'm also not totally convinced the internet model has all the answers yet, but I'm happy to see the progress made over the last several years. But I think that's really a different topic, so won't dive into it here.
I think my argument would be progress need to be made on both sides of the equation. Carriers should work towards being able to operate with the least privilege necessary (good luck... I don't have my hopes up seeing the inside), and still protect the privacy and integrity of the information it does need (routing locations, e911 services, record keeping, OTA updates, metadata).
That's a pretty low bar, because, as you say:
> SS7 is insecure
Also...
> operational practices at both the carriers and inside governments rely on those insecurities to get jobs done, and some of those jobs are important and enjoy wide support
Sure, law enforcement is easier then the citizenry isn't free. But the U.S. used to pride itself on being the one place on earth where that argument does not carry the day.
Perhaps give it a try yourself?
1.6 GB is the total image size - it's not all code, let alone OS or security-critical code. It's not all reversed from scratch every time a new update appears. It's not like the people looking at it are also staring at reams of ARM assembly. Etc, etc.
I don't know, but it's not hard to put an upper bound on it. A VT-100 screen worth of code is at most 2000 characters. If it takes me one minute to grok the code on a screen that's (again, at most) 33 characters per second. Even if we take this upper bound as the rate at which one can process object code (which, again, seems wildly optimistic to me) that's still several work-years to go through the iOS image.
> How do we know there isn't a secret backdoor in the Linux kernel and all of its drivers?
We don't. I don't claim that Linux is better. Go back and look at the context of my original comment. It applies to both iOS and Android. Tptacek's response veered the discussion onto iOS.
The problem is not that Apple or Google is evil or incompetent. They may be, but that's not the point. The problem is that these systems are too complicated, and the rewards for breaking them are too high. A back door in to iOS or Android could literally allow someone to rule the world (the President of the United States has been reported to use an unsecured phone). That is not a situation about which it is wise to be complacent.
> 1.6 GB is the total image size - it's not all code, let alone OS or security-critical code.
That is certainly true. But a back door can hide just about anywhere, so you have to look at all of it.
> It's not like the people looking at it are also staring at reams of ARM assembly. Etc, etc.
Yes, I know that. That's not really the point. Even if it were feasible to thoroughly audit the object code (I don't believe it is, but I'll concede it for the sake of argument) this effort is not a coordinated white-hat endeavor. Many of the reverse-engineers are black hats, or state actors not necessarily sympathetic to the needs of U.S. consumers. Even if they do find an issue it is not a slam-dunk that they will responsibly disclose it rather than attempt to exploit it for monetary or political profit.
Also, the focus on iOS is a distraction. Apple makes their own silicon. Vulnerabilities are probably more likely to be hiding there than in the software. Modern silicon is very hard to reverse-engineer.
1. We're talking about SS7 security.
2. Whether or not SS7 is secure, if your phone is compromised and hostile, it's game-over. So it's hard to see how this debate is even relevant.
3. You introduced the argument that Apple and Google phones were untrustworthy because nobody outside Apple (or Google) can audit them. You now say that's an overstatement.
4. When informed that there's in fact a whole cottage industry of people outside Apple who do audit iOS from binaries --- effectively enough, I'll add now, that they routinely find vulnerabilities that Apple missed despite Apple's privileged access to "design documents and source code" --- you express incredulity.
5. You denominate your incredulity in a "bytes per second" rate of reverse engineering based on compiled image sizes.
6. Later, you derive a rate from the number of characters you can fit on a VT100 screen.
7. You later clarify: we have to audit everything, you see: not just the kernel and privileged services but also every pixel in the Apple logo that appears when you boot the phone, and, of course, the security of the weather app.
8. Now we can't trust silicon either. Vulnerabilities are (???) more likely to be hiding there than in software.
This is a kaleidoscope of weird, wrong arguments about security, and, once again, has nothing to do with the thread. If you simultaneously believe all these things, it still doesn't make sense to try to protect phone calls by securing the SS7 network.
What I think you should do is take a simple binary from your desktop OS, download a copy of radare, learn how to use it, and blow your own mind about how even the free, open source reversing tooling works. I'm not being snarky. I think you'll be surprised by how this stuff works.
Second, let's try to achieve clarity on what it is we're actually disagreeing about here, because I'm not sure we even agree about that.
> no mass-market computing platform has been safer than the flagship hardware/software platforms from Apple and Google
I actually agree with that (though I wonder if leaving Microsoft off this list is actually justified, but that is neither here nor there). What I don't agree with is the implication that Apple and Google flagships are plenty good enough, and that buying phones from Apple or Google is the right answer to all our security concerns.
An analogy: before Fukushima it could be said of boiling water reactors that "no reactor design has been safer". Indeed, even after Fukushima the safety record of BWRs compares very favorably overall (in terms of casualty rates) with almost all other forms of energy. That doesn't mean that we can't do substantially better, or that we shouldn't try. But humans have always had trouble with low-probability high-impact events.
> 1. We're talking about SS7 security.
Well, sort of. The original topic was SS7 security (or the lack thereof). This is a somewhat unfortunate distraction because it led down a rabbit hole: yes, SS7 is insecure. But that doesn't matter much because most sensitive data that is transmitted by a cell phone nowadays is locally encrypted. But it matters some because most != all.
> 2. Whether or not SS7 is secure, if your phone is compromised and hostile, it's game-over. So it's hard to see how this debate is even relevant.
Well, SS7 is a data point. It is an existence proof that modern cell phone contain security flaws because they are the product of a long design process that has a lot of legacy from a time when security was less of a concern. If one such flaw exists, others might as well.
> 3. You introduced the argument that Apple and Google phones were untrustworthy because nobody outside Apple (or Google) can audit them. You now say that's an overstatement.
Yes, I chose my words poorly. A apologize for that.
> 4. When informed that there's in fact a whole cottage industry of people outside Apple who do audit iOS from binaries --- you express incredulity.
No, that's not fair. I am well aware that this industry exists. But I am skeptical that the existence of this industry is sufficient reason to accept the proposition that anyone who owns an Apple or Google flagship need not be further concerned about security, and I think my skepticism can be justified. Even if I'm wrong, I think my position is defensible. And I may well be wrong. That would actually be a good outcome.
> 5. You denominate your incredulity in a "bytes per second" rate of reverse engineering based on compiled image sizes.
I have a lot of reasons to justify my skepticism. I could write a paper (and maybe I should). But HN comments do not lend themselves well to long-form communications so I advanced what I thought would be a compact argument: a quick back-of-the-envelope calculation of the amount of effort required to audit iOS (which is just one component of an iPhone) would reveal that to be infeasible. Now, that calculation may have been way off. That entire argument may have been wrong. But I can always fall back on the fact that to prove that there are no security holes in iOS you would have to solve the halting problem (specifically, you would have to solve the lambda-equivalence problem, which reduces to the halting problem). So I'm pretty sure I'm on solid ground with at least some level of skepticism about the effectiveness of reverse engineering.
> 6... 7... 8...
Yes, because the position that I'm arguing for is that there are a lot of potential problems that the reverse-engineering industry is not well equipped to address no matter how effective its tools are. And furthermore, even if I'm wrong about that, that is still not enough to justify the conclusion that owners of Apple and Google flagships need not be further concerned, because it is not just the abilities of the reverse-engineering industry that matters, but also their motives. And I see a lot of grounds for skepticism about that.
> it still doesn't make sense to try to protect phone calls by securing the SS7 network.
Yes, we agree about this too.
> radare
I was not aware of radare, so thanks for that pointer. It does appear to be a very impressive and comprehensive collection of tools. But one thing that it doesn't have (AFAICT) is advanced AI that automates the process of extracting algorithms and intent from object code. So at the end of the day, you still have humans searching for needles in a 1.6GB haystack.
Another thing to acquaint yourself with --- orthogonal to the Radare pointer --- is the concept of a "lifter". Or, in another direction, with symbolic execution. Or, still another, with modern decompilation tools.
https://en.wikipedia.org/wiki/Courtier%27s_reply
So it doesn't seem to me that continuing this is likely to be productive.
Neither of these are serious, engaged-with-the-actual-topic sorts of arguments. It's a little rich to be coming back with a grumpy note on the taxonomy of logical fallacies.
https://en.wikipedia.org/wiki/Straw_man
"A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent's argument, while actually refuting an argument that was not presented by that opponent."
I mean, really?
To be perfectly clear (since misunderstandings seem to be running rampant in this thread) I did not literally pull that number out of my hat. That was a figure of speech, meaning that I picked a number that seems not-entirely-unreasonable but which I didn't really give a whole lot of thought to because the exact value is not essential to my argument. No matter what wizardry your tools provide, it seems exceedingly unlikely that you're going to burn through the code at, say, 100 bytes per second without running the risk of missing something. So the question of what you consider a reasonable estimate was deadly serious. If you think my estimate is wrong, then tell me what you think the right answer is and why. The fact that I didn't put a lot of effort into my analysis is not in and of itself a valid criticism. Sometimes people get the right answer for the wrong reasons. (In fact, I am in the middle of preparing a series of lectures on the history of science, and it turns out that it is usually the case that the first time someone gets the right answer that they get it for the wrong reasons!)
Fair enough.
No matter what wizardry your tools provide, it seems exceedingly unlikely
Wait no, this is wrong. Experts are telling you this is wrong. Non-experts (say, me) looking at the same stuff can easily see that it's wrong.
If you think my estimate is wrong, then tell me what you think the right answer is and why
I think I saw some tptacek comment in another branch of this thread about 'how many bushels does it take to get to space'. I think he's right that your arguments are in that exact realm of underinformed inarguability. I don't have to prove the halting problem to reasonably say that an airliner, with all its software, is a more reliable and safer form of transportation than a snowboard. Yet you bring this up as some sort of meaningful retort. The onus is not on me to show reasonableness.
So, first of all, I am an expert. I am not on the level of tptacek, but I did not just fall off the turnip truck either. I have a Ph.D. in computer science plus ~30 years of industrial and research experience. I've been studying security and cryptography for ~20 years. I run a company that sells a security product (https://sc4.us/hsm) for which I wrote much of the code myself. One of the reasons I'm skeptical about the security of iOS is because I know how easy it would be for me to conceal a back door in my own product, and my product has orders of magnitude less code and correspondingly fewer places for vulnerabilities to hide (which is supposed to be one of its main selling points, BTW).
Second, it's simply not true that experts are telling me that the "this" you are referring to is wrong. The comment to which you are responding is the first time in this thread that I have raised the amended claim that the rate of decompilation is <100 BPS rather than ~1 BPS. You are the only one who has responded to that so far.
Third, while it's true that tptacek has been telling me that I am wrong, he has been very vague about what exactly it is that I am wrong about. He has not directly challenged any of my claims, not even (if you read carefully) my conclusion. Neither he nor anyone else has actually made a made a statement of the form, "You're wrong, a reasonable estimate of decompilation rate is X", or, "You're wrong, a complete audit of iOS can be done in X work-days." All of the responses have been of the form, "You're wrong because you're an idiot," or, "You're wrong because you don't know the ins and outs of contemporary reverse-engineering techniques." But that, as I have noted before, is the courtier's-reply fallacy. Even if I am ignorant it does not follow that I am wrong. People get things right for the wrong reasons surprisingly often.
You're right, this line of argument about expertise was generally unproductive and I shouldn't have gone down it. I apologize for starting it. It's dumb and it's dumb no matter how much of an expert you are or are not.
I stand by 'unserious', though. 'image size' and 'halting problem' are two deeply unserious retorts to the points others were making in this thread.
BTW, you can only "stand by" something that you have previously said, and AFAICT you just now introduced the word "unserious" into this exchange. That, to me, is an indication that you are not taking this very seriously.
"Neither of these are serious, engaged-with-the-actual-topic sorts of arguments. "
That's the bit I stand by.
"first you claim that an iOS image is a black obelisk fathomless to man and when challenged and essentially forced to concede this is completely inaccurate you fall back on saying your position is generally right and what's more, both right and unfalsifiable because of Archangels Turing & Church. Neither of these are serious..."
You're right, neither of those are serious. But neither of those are my argument.
So I guess we actually agree about that.
"But I can always fall back on the fact that to prove that there are no security holes in iOS you would have to solve the halting problem"
This is not a serious argument. You can say it about anything and declare up-front that no matter what, you're going to be 'right'. It would be mildly amusing in a dorm room chat around a bong. It's an embarrassment to say it in full seriousness and then indignantly point at your CS PhD. Now you won't even admit you even made it. The (now-distant) sibling comment is right - even in the unlikely event we moved past this, your next Atlantic Wall would be Penrose quantum consciousness.
Why not? Do you not believe that it is true?
> You can say it about anything
Well, yes, the halting problem does have some rather far-reaching consequences. (There's a reason Turing is famous.) But there is an important sense in which the halting problem is relevant here: security is adversarial, and so the limits on computability matter more than they do in a non-adversarial context. In a non-adversarial context, the odds that my system will behave according to some simplified model are higher than in an adversarial context, and that often makes reliable analysis feasible, the halting problem notwithstanding.
BTW, I am not waving my Ph.D. around to convince you that I'm right. I'm waving it around to try to persuade you that if you disagree with me, it might be because I have a point that you are failing to grasp, and it might be worth your while trying to understand what that point is even -- perhaps especially -- if it turns out to be wrong. But simply proclaiming my argument to be "non-serious" is not a productive first step.
Of course I believe it's true. I also believe it's true that there is a non-zero probability that if my phone were stolen, the air molecules around the fingerprint sensor could spontaneously come to an electromechanical arrangement that unlocks it, giving the thief full access to my bank account and terrible taste in music.
I (and I imagine you) don't claim I was late to an appointment because of heretofore unforeseen difficulties in hidden-variable theory.
On the other hand, the probability of a skilled adversary introducing a back door that evades known methods of detection is very much distinguishable from zero. Heck, the probability of a bug introducing a back door that evades known methods of detection (at least for a while) is distinguishable from zero! That's why jailbreaks are possible.
No, I did not say that. You keep putting words in my mouth, starting with "an iOS image is a black obelisk fathomless to man". And yes, you did quote me, but you took the quote out of context and then twisted its meaning.
Here is what I said:
> I have a lot of reasons to justify my skepticism. I could write a paper (and maybe I should). But HN comments do not lend themselves well to long-form communications so I advanced what I thought would be a compact argument: a quick back-of-the-envelope calculation of the amount of effort required to audit iOS (which is just one component of an iPhone) would reveal that to be infeasible. Now, that calculation may have been way off. That entire argument may have been wrong. But I can always fall back on the fact that to prove that there are no security holes in iOS you would have to solve the halting problem (specifically, you would have to solve the lambda-equivalence problem, which reduces to the halting problem). So I'm pretty sure I'm on solid ground with at least some level of skepticism about the effectiveness of reverse engineering.
That does not mean the same thing as "any argument or assessment of the security of a phone can be dismissed by virtue of the halting problem." If you don't understand that, I would be happy to try to explain the difference to you. But you have reached the limits of my patience with your straw-man arguments. Do it one more time and we're done. Life it too short.
I mean, it's in your own damn text. What on earth does this mean that is different from what I think it means. I'm perfectly happy to hear your explanation.
The quote is accurate. Your paraphrase of it is not.
> I'm perfectly happy to hear your explanation.
OK.
My invocation of the halting problem did not apply to "any argument", it applied to one specific argument, namely, the argument that because I was ignorant about the details of modern reverse-engineering techniques, that therefore my conclusion about the likely security of iPhone was wrong. There is still the possibility that someone else could raise a different argument for why iPhones should be trusted to which the halting-problem objection would not apply.
Also, I did not "dismiss" the reverse-engineering argument. It's possible that the reverse-engineering community has figured out some devilishly clever way to work around the halting problem for all practical purposes, and that I'm just unaware of this. If they have, I'm perfectly open to being convinced. (But I'll give you long odds against.)
did not apply to "any argument" [...]
What you said is plainly preposterous and ridiculous. I'm happy to discuss anything you said and anything I said. But, sputter this came out of your own effin mouth. I am not going to talk about how it's something other than its plain meaning.
"But I can always fall back on the fact that to prove that there are no security holes in iOS you would have to solve the halting problem"
The fact that you are focused on insisting every byte of the code indicates that you are not yet familiar with the process of how this works.
By way of background, I have done security source code audits of systems on the order of 750,000 lines of code. This was done in a 12 week effort. The approach taken with source code review is possibly different than you think. One part of the approach is to look for patterns of code that are known vulnerability patterns, such as sql injection, or opening a socket. You then trace back to code paths that lead to that to determine how external input (that is user-controlled or attacker-controlled) can be use to trigger those vulnerable pieces of code. Another part of the approach is to look at each of the inputs (or interfaces) to the code to determine how those inputs can influence behavior of the program. One is likely to switch back and forth between these instances.
One key approach in looking at the code is to ask "can user input cause the program to choose one path of a branch or another." Another key approach is to ask "can the user's actions cause a change in one word of the programs memory." From that, an exploit can be crafted.
So you might well now ask "ok so that is source code. Object code is orders of magnitude more difficult." This is not really the case. The tools that 'tptacek mentioned take apparently impenetrable object code and transform it to assembly language (as well as to an intermediate language ESIL), and answer many questions about the static and dynamic nature of the code under inspection. Also, you can get differences of the call graphs from one version to the next. This trick was used to detect a vulnerability resolved by a Windows patch in a common library. It was noted through this tool that there was another use of this library elsewhere in the system that left the vulnerability in. This is without having source.
In fact, for the most serious level of analysis, one should go directly for the binary, as who knows how the source code actually corresponds with what binary actually gets shipped.
And it turns out one can effectively audit code for a language that one is not an expert in. The key elements are "where are the branches" and "what are the call graphs" and "what are the inputs and outputs".
In another thread, you note that you are an expert and that you are involved in the production of a security product. I am as well, having been in the software development business for 52 years, the last 10 in the security field, focusing on software security. And I can testify that these are two different fields of expertise. An expert in software development, even of security products, does not automatically mean that one is an expert in finding security flaws in code.
I've trained many software engineers in software security, and a key part of that training is to note that software engineering builds up programs and solutions by using previously developed abstractions, and making new abstractions that use existing ones. A penetration tester will develop skills in penetrating abstractions. It is a different way of thinking, a different kind of expertise. It is clear from your work that you are excellent at building up abstractions.
There are a couple of ideas that you are missing, I think. One is that evaluating the "rate of burn" through the bytes of a binary blob is a useful way to determine the difficulty of assessing the security. (Nor is it a useful way to evaluate software productivity) It is not necessary to look at every byte. Think of looking at every basic block. I suspect you will get a number that is different by two orders of magnitude than what you are currently thinking.
That is true, I'm not, certainly not with the details. I hire people to do audits and pen-testing for me. But in order to be able to distinguish people who are competent from snake-oil salesman, I have to have a pretty good grip on some fundamentals, and I believe I do. So even though I have not used a modern decompiler, I certainly know that they exist, I know the fundamentals of how they work, and I know their limitations. I know, for example, that information is lost in the process of going from source code to object code to decompiled code, so the process of auditing decompiled code is necessarily strictly more difficult than auditing source code. I also know that the relative sizes of the source, object, and decompiled code is more or less linear. (A few things deviate from this, like C++ templates and unrolled loops, but it's true to first order.) So using a linear approximation to get an estimate of the amount of work required to audit a binary blob is not entirely unreasonable, particularly since the only question I'm trying to answer is whether or not it is even plausible that iOS could be effectively audited by an unauthorized third party given its size. (Note that even if the answer to that turns out to be "yes", that still doesn't demonstrate that iOS actually is being effectively audited.)
So:
> It is not necessary to look at every byte.
I never said it was. Nonetheless, unless some auditing technique is effective enough to change the (first-order) linear relationship between source code, object code, and decompiled code, or effective enough to introduce a radical linear multiplier (i.e. eliminate 90% of the code from consideration) the fact that not every byte needs to be examined is irrelevant. My first-order estimate will still be good enough to provide a plausibly correct answer to the question I'm asking.
> In fact, for the most serious level of analysis, one should go directly for the binary, as who knows how the source code actually corresponds with what binary actually gets shipped.
Yes, exactly right. Nonetheless, this process is easier if you have the (purported) corresponding source. More information is always better.
There is one more important point that you seem to have missed (along with everyone else): there is a big difference between trying to find a vulnerability that is the result of an inadvertent bug, and one that has been introduced deliberately by a competent adversary. Finding the latter is vastly more difficult than the former. Decompilers operate on heuristics. Heuristics can be fooled. One of the things that a competent adversary would do if they were trying to hide a back door would be to put it in a form that causes it to be hidden by decompiler heuristics. So this entire discussion about reverse engineering techniques is actually totally moot. Writing a decompiler that did not have this problem would require solving the halting problem, so even though I don't know the details, I know they have this shortcoming. Not only that, but I know how I could identify the specifics of this shortcoming, and I know how I could write code to take advantage of this shortcoming to conceal a back door. And if I know these things, then there are certainly people at Apple who know these things.
This is the reason that I am quite confident in my position despite my ignorance of the details of modern reverse engineering techniques. The halting problem gives the advantage to the attacker, and no technological advance is going to change that. It's like a second law of thermodynamics for security. I don't need to know the details of contemporary technology to know that, all else being equal, the person trying to hide a back door in a 1.6GB binary is very likely to beat the person trying to find it. And the problem is not just technological. As I've pointed out elsewhere in this thread, even if someone does find it, that knowledge will be extremely valuable. It is far from clear that anyone who succeeds in finding a back door in iOS would use that knowledge for the public good, particularly when you consider the personality types and economic circumstances that lead people to pursue a career in reverse-engineering in the first place.
This situation is ridiculously complex, and that complexity extends far beyond the size of the iOS binary. Anyone who is quibbling over my 1-byte-per-second estimate, or my personal proficiency with radare, is missing the point rather badly.
Your arguments here pile non sequitur atop non sequitur. I'm left with the impression that this is a topic in which you've decided you're unwilling to concede anything. No doubt, if I challenged you about how difficult it is to reverse hardware, you'd pull some other weird rabbit out of your hat, like quantum states or interactions between circuits and cosmic rays.
Of course, if you'd led off your argument with "cosmic rays make all of information security in some ways unknowable", we'd all have simply said "sure, but that's besides the point". But that's not your argument. Your argument is that telcos should provide cryptographic security for telephone users, because Apple has insurmountable advantages against its users due to its access to its own source code. No, that doesn't make any sense.
I'm not taking it personally or anything. You've just gone on tilt. It happens to all of us. For what it's worth: I think you still share a Slack with several of us? You could ask this question there, and I'd be more comfortable responding in detail there.
I've already conceded that I am ignorant of many of the details of modern reverse-engineering techniques, so that is manifestly untrue.
> you're not even in the ballpark of correct
You keep saying that, and yet you don't back this up with any details or supporting arguments. In what way am I incorrect? Is my estimate too high? Too low? By how much? Am I wrong when I claim that a lower bound on the computational complexity of auditing is O(n)? If so, what is the correct result? Is it O(sqrt(n))? O(log(n))? O(1)?
BTW, I would actually love to be convinced that I'm wrong about this. That would be a huge two-fold win for me. It would mean that 1) I can stop worrying about security (as long as I use an iPhone) and 2) I would learn something new and almost certainly very interesting. But you (or someone) have to tell me how and why I am wrong, not just that I am wrong.
It would also help if you would stop stop advancing logical fallacies like this straw man:
> cosmic rays make all of information security in some ways unknowable
I don't understand why you're more comfortable discussing this on Slack, but OK, I've fired up my Slack client.
> You're not even counting the right thing. How many orders of magnitude off you are isn't even the most important problem with your analysis.
It's more than a little disingenuous of you to say that without saying what the most important problem is. How exactly did you expect me to respond to this?
I edit comments to refine language but never to change their meaning.
No, I don't agree that I'm being disingenuous.
Because if you are named Google, for instance you have a very big safety to know pretty anything from anyone thanks to your spy network everybody use, want to use, buy from you, more and more.
However if you are a "typical citizen" well... You have less and less choices, for instance you want a classic mobile phone? Good luck to find one. And even if you find it did it still can operate? In many developed country we start talking about cutting GSM/2G network leaving only 3G backups and invest in 4G massively...
Do you want a car that you and only you can control? Hum... Ok... You have few options: buy a history car (feasible if we do not need to move too much until we close gas stations transforming them to recharge stations) or create one from scratch and good luck not only for the technical part but also for the needed bureaucracy to get them legally usable on roads.
That's the problem.
Today dictators does not need strong power anymore: why forbid traditional non-connected, non-autonomous cars? You simply stop to produce them. With actual centralization is super easy.
We are NOT in a free market capitalistic society, we are in a kind of planned economy not much different than Soviet Union's one, only instead of a formal dictatorial government, with clear powers and symbols, we have a vague corporatocracy without symbols and formally "constrained" by some kind of "democratic laws". And that's is even worse than classic dictatorship because with them you know your enemy, now you can't really know it and you can't fight an enemy you do not really know nor see.
It would take me a 15m walk and $20 to get a basic dumbphone right now. Where do you live that these are hard to find? Or do by "classic", do you mean old? But if so, what's the advantage?
But the classic phones are exactly those that run a closed OS and only support protocols (SMS and phone calls) that can be spied upon by the ISP. If you don't trust Google and Apple, why would you trust a classic phone?
Do you want a car that you and only you can control? Hum... Ok... You have few options: buy a history car (...) or create one from scratch
Infotainment systems have been becoming too invasive, yes, but you still have options. For example, the Nissan Micra comes with a FM/AM radio with MP3 support. No GPS, mobile data, etc.
I live in south France, and I have zero idea where to find something like a Nokia 3310... Now, and not for now, I only see smartphones of various (crappy) kind or phone for old people that mimic classic phone but with a crappiness of '90s-style dot-com era business software...
Of course 3310 was proprietary but simple enough to have fable means for spying me and the level of centralization is far, far less than now. Banally yes, my carrier can spy on me. But only my carrier, not a super-giant multinational data-mining company. And my carrier is subject of my country's law I know a bit about so I have a certain protection. With Android&c devices there are tons of different subjects that can spy on me from any country of the world. I have essentially ZERO protection. And modern devices can do far more than mere audio recording at carrier level...
> Infotainment systems have been becoming too invasive
Oh but I do not really care about infotainment I do care about being unable to switch ABS off when on snow so to have chances to brake the car under my own control, I do care about the ability to switch on the engine without any possible software crash interference (a friend of mine remain locked inside it's top-of-the-line Audi because of a software fault, for instance). I do care about NOT having the ability of power on my car via a smartphone witch means having a remote control device that connect my car with it's vendor and me via internet, all on proprietary software I do not know nor control.
I can't really use a Nissan Micra, I normally use a car for 30-60Km to 300+Km trips, not distances nor environments to be done with a citycar...
And even on simplest citycars: a friend of mine few days ago ask me if I can help because he left light on and shes car's battery is drained. I came, it was evening with not good light and it's raining. I see a big red plate aside a pole of the battery and a black cable on the opposite pole. My cable nipper start sparking fire suddenly when I connect what I'm thinking it was the + pole... With sound imprecations I grab a headlight and see: TWO damn battery poles are without a fucing +/- sign, TWO have black big cables and the damn big red plate have a rigid connection UNDER the plate, black painted as the battery, that attach it to the farthermost* pole. I do not know how an mechanical engineer can be so dumb to design such a thing.
20€ with free shipping: https://www.boulanger.com/c/telephone-portable-sans-abonneme...
And this year they even released a model with 4G support, reducing the fear of network support shutdown.
Regarding cars, fair enough, I don't even drive, so I don't have a good knowledge of what's available. I do doubt you'll find any car built in the last 30 years without any software, but if it's running fully locally, I don't see how it's that different from any other custom part. If the locks in your friend's car used a simple electrical system, and it broke, he would have been just as stuck.
I talked about infotainment because they often come with Internet connection and such, which is different than just replacing parts with software, but as far as I know, you can still find many models without it.
On car's being softwareless is not exactly a thing I'm look for at least if software is free, community accessible and well peer reviewed and I can modify it without need super-complex and expensive stuff. The problem "modern" design: for instance ABS really save life in some conditions, like on dry od rain-wet roads. However kill's you on icy roads. In "ancient" cars there is a button to deactivate ABS when you want. Now it disappear. Modern cars have small stereocam and other sensors that try to look around and eventually act on brakes, for instance if you fall asleep driving and you are about to crush into an obstacle the start to shake steering wheel and soft break, if you still not react strongly brake the car, light up 4-way directions etc. Really useful however if you deliberately choose to crush on an object, for instance to avoid a group of children you simply can't. If you deliberately choose to go offroad because you see a big trailer full of kerosene or other combustible about to crash and explode at your side you can't. For that kind of driving aids, for now, we have normally a button to disable them. But it's probably the same story for ABS, at first deactivable after always on.
I here nth time the story that on planes and ships you can deactivate autopilots and pretty any feature because pilots, maritime personnel etc are properly trained while drivers tend to be not much but that's an absurdity the correct, logic, acceptable answer is "add training". Not much difficult. Thinking that a software can be better than a human is a thing we already heard in the past with Microsoft and I think we all agree that's not a good idea...
How are they different with regards to the stuff we were talking about - specifically, the centralized spying and such?
I've used a Wiko Lubi for a year. It seems to have the architecture as a 3310: it has a basic burned-in OS, without any apps or updates, and has a few basic tools like a calculator and calendar, besides the phone calls and SMSs. In what way does it not fit with a classic model?
If your complaint is the exact same models don't keep getting produced, then sure, but that wasn't the discussion I thought we were having.
Regarding cars I won't comment any further, since I don't know the market well.
If you still have ancient Nokia try only the feeling of their physical keys, the simplicity of their classic menu compared to those modern "devices"...
That’s all possible today.
Meta data is much more powerful than is commonly supposed. Timing attacks are at least as effective as keystroke statistical attacks, which are real. You're better off, if both of you are running VPNs all the time and have lots of background traffic on the same connection.
Consumers are more likely to switch because of coverage than security.
This is, perhaps, because they aren't informed that their communications aren't secure and that coverage is extended despite being insecure.
SS7 is not a "cell tower protocol", its an entire protocol stack that allows a Telco central office switch to talk to any other central office switch on any other Telco anywhere in the world, for both copper and cellular subscribers. It run's the entirety of global phone. Class 5 Telco switches are often old Many of these switches have been in service since mid 1970s. Do an image search for "Nortel DMS 500" and you will get an idea of how old and stodgy a lot of this gear is. And it all needs to interoperate seamlessly as governments, emergency services etc all rely on it. In fact with they add IP capability to SS7 - SIGTRAN, they basically forklifted it as is, warts and all. Presumably to err on the side of caution.
A handset only implements a small subset of the SS7 protocol stack the Mobile Application Part(MAP.)
What does one do about that?
I think it would be amazing if banks and financial institutions used iMessage but I can’t see it happen.
The 4G backend still has a web of trust between operators and their e.g. IP exchange providers. As far as I know, this will change with 5G.
Roaming data confidentiality can then be routed and encrypted until the home operator network, while the associated metadata is accessible for the IP X to provide their services.
The home operator can verify the smartphone is actually in the visited network.
These are all bits and pieces that break up the operator's web of trust.
https://www.aftenposten.no/verden/i/Olkl/Sources-We-were-pre...
Am I the only one often peeved by this kind of slop in thought and expression? Of course somebody could. Some visionaries even did, and not than just Arthur C. Clarke.
So rightly: 'Few envisioned how deeply ...'
We have the means to have secure communication over insecure channels with asymmetric crypto signing+encryption (which doesn't seem broken at least for now), the problem is semi-solved at the software layer -- we now need to solve the privacy/security issue at the layers below software.
[0]: https://riscv.org/
[1]: https://riscv.org/2018/10/hackaday-article-new-part-day-the-...
It's becoming increasingly common to rent portable wifi devices from 3G carriers, and if long distance wifi mesh networks ever take off things will be even better.
The idea is to not have your primary mobile computing platform be compromised, if you can prevent it.
Also, see the sibling post to this -- https://www.gl-inet.com/products/gl-mifi/
Isn’t this one of the major selling points of iMessage etc?
I would love to do an examination of communication via BankIDs app to the internet to see what kind of security exists to protect the user. If you can get the person's social number (personnummer) and their 6-digit code, then spoof their device (probably the easier part) you can basically take over their life in Sweden.
The fact that cellular traffic to this day isn't encrypted properly[1] even though LTE was supposed to should indicate just how horrible cellular providers are at infosec & what happens when they drive security requirements.
[1] https://arstechnica.com/information-technology/2018/06/lte-w...
The article is about the basic communication between the phone and the cell tower, which has other issues.
Unfortunately the very same power is interest for criminal itself to spy on their targets, any kind of criminal from the home thief that may like follow you to know when you go on holidays, what kind of safety you have at home (because yes, you post new shiny photos of your new home surveillance system, together with it's plan, photos of you and few technicians during the mounting phase etc), what you have in your house (because you post tons of photos/selfie with relevant "background") to your insurance company that buy with discretion your data from Amazon/Google/Microsoft/Apple, data recorded by voice assistant, smart devices with cameras everywhere, speaker mic of your phone etc (curiously in the past such kind of spying devices were buy, and they are very expensive, by people who want to spy on you. Today you buy them from the people willing to spying on you and also you pay connectivity and electricity form them) to your government that likes to know your political opinion and influence network like ancient est-German STASI or modern NSA/FBI/CIA/* do.
The real "safety" point is not safety itself but balance of power. A knife good to cut a succulent steak is also good to kill someone and perhaps to open a package. A car the same. A phone the same. etc. They are instruments with more or less effectiveness, comfort and power. If they are balanced so anyone have more or less the same power we have no real safety problem. If too few have too much power we have a problem, bigger as fewer and powerful counterparts are.
Unfortunately to proper balance power as a society we need also a certain level of awareness and civic sense distributed among us, because yes knowledge is power. At any level. Today's and not from today's we evolve in a more and more ignorant society with a more and more reduced élite that rules against tons of sheep.
Fortunately I'm having a little bit more luck on my current project in the health space.
1 - You remove control of the company from being able to plausibly deny that something happened; you become a second subpeonable party that would disclose something if forced to. 2 - You're not pricing it high enough for a big reseller (like CDW, etc) to want to try to sell it.
Not sure how to fix #1 besides selling/licensing the tech (if the patent issues) to a larger company that can roll this into a larger offering (and out to their exiting customers).
Background; I've worked in Enterprise Software Sales and as part of a SaaS Operations Team.
The value prop I tried to push for MSP resellers was that it would result in more incident response work for them. Basically offering to white-label the thing.
Please tell me this is a joke.
Big institutions are fundamentally feudal organizations. If you look back at medieval times, some of the lords and dukes were wise men driven by some higher purpose. Others were not.
The tools have changed, but people are the same.
It’s also why regulation is so important. Like feudal lords, the agents of the overlord (ie the auditors) are feared and respected. Compliance tied to compensation or continued employment is something that is cared about.
(1) https://www.cancer.gov/about-cancer/causes-prevention/risk/r...
This is a tired response that everyone memorizes but fails to back with facts.
1. There are studies showing some effects besides DNA mutation, such as heating, due to non-ionizing radiation, which could cause a number of health effects.
2. The World Health Organization classified cell phone radiation as a potential carcinogen. The CDC has stated that there is no conclusive evidence one way or the other on whether cell phones cause cancer.
3. I said "potentially" above.
A more dangerous Group 2A includes red meat, "Shift work that involves circadian disruption", and "Very hot beverages (more than 65°C)", according to Wikipedia.
Group 1 contains UV light.
So, walking outside in a sunny day sipping coffee after eating BBQ with kimchi is probably more dangerous than cell phones. Doubly so if you're a firefighter.
Your phone is with you at all times of the day, always within 5 feet of your person, which means that if it leads to cancer (which we will likely find out within the next 30 years since American children are now surrounded by phones and tablets from age 5) then it's much more likely that you end up with cancer because of your phone rather than the fact that you were out in the sun for an hour every day.
But walking outside in a sunny day is in a completely different category. Your comparison at the end is severely unbalanced, the Sun alone overwhelms everything else on both sides by a huge margin.