Apple, Google Diss the DoD Over Mobile Security
Julie188 writes "The Defense Information Systems Agency (DISA) has long supported the use of BlackBerry smartphones for soldiers. It built a system called Go Mobile to provide secure communications, training, and collaboration applications to mobile soldiers. DISA recently decided to add Android and iPhone to the list of approved devices because of high demand from users. Unfortunately, this choice has become a giant pain in the flank. Why? Because both Apple and Google refuse to give DISA access to their security APIs."
TFA is very light on technical details. What security API are they looking to access? To do what? They have access to AOSP/Linux, and could even cook up custom ROMs if they needed. Is there some cryptographic hardware driver they need or something?
Also, From the 'article'
It seems to me that Apple and Google are making self-centered bad decisions here that won't play well with the American public. Clearly, Apple and Google should re-think these myopic and selfish policies
WTF? Maybe this journalist should re-think his self-centered trite opinion fluff pieces. Oh wait, it's NetworkWorld. Not much chance of that happening I guess.
meep
Shenanigans! There's got to be more to it than this.
The entire source for Android is available; what could Google be holding back? It's not as if they manufacture the phones.
What are these 'Security APIs'? It doesn't make any sense.
I think it's more likely that the DoD asked for some of Google / Apple's signing keys and the companies rightly refused.
According to the article, practically the only reason given as for why Google and Apple should give access to these APIs is to be patriotic. But as a few other people have pointed out, Google and Apple, though based in the US, are no longer solely US companies. What would this article's opinion have been had Russia or China or some other countries equivalent Department of Defense had asked for access to these APIs I wonder?
IMO, My device is not "secure" unless I can control the device's OS & inspect the device's hardware. My phone, my router, my PCs, my GPS, all have firmware I've compiled myself.
This doesn't make it secure. It just means that if someone's made a mistake, or inserted a backdoor, you've missed it. Control != Security -- sometimes it just creates a poor illusion of security. If you don't have control, you have to trust someone to provide security. Depending on who it is and what their experience is, I often prefer to trust.
Regardless, one of the big issues that I've seen in this area is that although yes, you CAN jailbreak iPhone or install custom firmware on whatever device you want, you want the ability to deploy commercial-off-the-shelf stuff to users in the field with a 10 second install from the app store. They want to leverage the existing distribution network for the product and application distribution for software packages. They want to piggyback off the commercial world with minimal development effort and cost. What you're proposing a better model from a secure perspective, but is massively more expensive.
I know this is Slashdot and all, but still:
IMO, My device is not "secure" unless I can control the device's OS & inspect the device's hardware. My phone, my router, my PCs, my GPS, all have firmware I've compiled myself.
This doesn't make it secure. It just means that if someone's made a mistake, or inserted a backdoor, you've missed it. Control != Security -- sometimes it just creates a poor illusion of security. If you don't have control, you have to trust someone to provide security.
I write code. I read code. Yes someone can make a mistake, I can miss the mistake, but I can also fix said mistakes as soon as the mistake is discovered. You can't do that unless you can compile your own OS / Firmware. Faster Fixes == Less Vulnerability Window == More Secure. I'm not arguing that open source makes something secure, but using the source can give you more security than otherwise.
If you argue that control != security, I will put it to you that the inability to Control = No Provable Security. Thus, Control = infinitely times more secure than uncontrollable. How secure is a device that can auto-update it's firmware without your consent?
Depending on who it is and what their experience is, I often prefer to trust.
Let us not forget that I am compiling the same sources that those you "often prefer to trust" are compiling; Except that I am also sure that no additional closed source code has been included in my build.
Binary_Blob == !Trust;