[K3_Cubed]

There is indeed a PDF! The link is kind of buried at the bottom of the webpage I gave you, but here's a direct link to it: https://www.cl.cam.ac.uk/~rja14/musi...ripts/SEv1.pdf

It's a rather old book by now, so the examples are outdated (you'll see lots of mentions of Windows 2000) - but the principles still hold true. Very long read though, expect to take a while to finish it, but it's an excellent primer on a wide variety of topics in security engineering.

Good information is good information... it doesn't really matter if the references/analogies may be outdated, once the underlying principles are there that's what I care about. It seems to be a very good starting point into security concepts in general, so I will definitely be adding to my library....

Pokemon Go simply wouldn't work without location data, as an easy example.

Yes I know some apps do legitimately require the access to some permissions, however my concern was as you said, some apps may mask ulterior motives using seemingly valid permissions or may not even give you the option to revoke those permissions. I know I had an app that did not allow me to revoke certain permissions (almost all!) and I had downloaded it from a certain developer in Blackberry World... I don't know if it was an error or what. Tried rebooting to see if it was a glitch and I still couldn't revoke permissions.

Based on what you talk about for the App Store and it's apps (or maybe within the OS itself), there doesn't seem to be the ability to prevent permissions from being revoked by the user. That may either be a function of the filtering process of apps that get submitted to the App Store or the SDK just doesn't allow the developer to prevent revoking permissions.

However from your explanations the app level control seems to be similar to what most OEM's offer, but iOS even goes further to revoke (at least location) permission from SYSTEM or OS LEVEL processes which is neat. I am not sure how this compares to the Android/Windows Phone platforms. I think it is generally either a binary choice (again at least with the location) of either ON or OFF with the other systems including BBOS. Don't think it gets more fine tuned than that. And that's just my personal opinion based on browsing through settings for CyanogenOS on a Nexus; and Windows Phone 8.1 on a Lumia. Anyone with further information can clarify.

...64-bit iPhones are really preferred...

Regarding this, how do you tell the 64-bit from the 32-bit iPhones.... as far as I can tell there have been no real marketing or model number differences that I can say would lead me to believe that there wasn't anything other than one fixed version for any release... Or are you referring to generational differences: for e.g. earlier iPhones would be 32-bit whereas later iPhones would be 64-bit?

You seem to be quite knowledgeable with regards to the security aspects. Is the implementation of the "Security Enclave" in the 64-bit processor for the storage of the device encryption key different / more advanced / less advanced to how Blackberry implements their security checks? I'll need to update the post above to reflect some of what we talked about here but I'll wait for some of your feedback first whenever you have time. (i'm afraid by the time I finish update the Original Post I may have to write it over again because it'll be outdated.... )

[K3_Cubed]

The problem is that companies must find the best balance between security and usability. If Google really wanted to make Android more difficult to exploit, they would just disable sideloading apps altogether and only allow apps to be downloaded from Google Play. Most malware is spreaded through 3rd party store or cracked premium apps.

But the enthusiast community would riot over this. And that's the problem. Most of the enthusiast community have at least some common sense and and most of the time what they are doing. Their tinkering with Android goes up to rooting their device and I doubt many of them actually got malware out of it. The security for the average user, show doesn't tinker that much (or at all) would definitly improve by restrincting certain things in Android, but then Android would lose part of its identity and appeal.

Whew... sorry man... I really just got snowballed with LazyEvul and reading and responding to his post that I completely forgot your contribution... Blame him lololol. Anyway, yes I understand what you are saying, and this was a aspect which I did not talk about enough on in my first post.

All exploits, arguably, after having been found, would need a means by which the exploit could be implemented. Now you have mentioned one of the most obvious ones... those pertaining to app installation and their permissions.... also their relevant malware coding inside. But what about exploits that don't need the use of a third party app install. Those that can be exploited through stock features.

I am not nit-picking or scare mongering, but the clearest thing which comes to mind that pops into my head would be the compromising of the Marshmallow OS through a simple text (which I think has since bee patched). Now I agree that this is a relatively unique exploit and we may not ever see a text message exploit again (at least we hope not). I am talking about things with how the OS handles internal memory/communication/"drivers" etc. The inner workings which are needed to perform everyday functions.

From the little I understand of Android, it has a Linux base on top of which sits the "Dalvik" platform which is essentially the platform that allows it to run all it's apps. Dalvik is Java based and this is what enables the use of applications and the Google Play Store. I think Google designed it that way to get a large existing base of developers to develop for the android platform given the prevalence of Java. It would be interesting if the exploits and malware are focused on the Dalvik frontend or the core Linux base... (or maybe equally, I dunno). But from using the Java on my PC over the years.... there have been FREQUENT updates, many of which state it fixes a "critical issue". Don't know if the issue is performance related or exploit related, but it has always been the one software that gets updated like crazy (until MAYBE in recent years where updates feel a little more spaced out). I can understand if malware was directed specifically at Dalvik...

Anyhow, irregardless of this, what matters is how the exploit is initiated. You mentioned the third party app route and that's valid, but what about through normal system usage? Is the potential exploitation pretty much basic as in using a Windows PC where if you mind your P's and Q's and don't go browsing to far, or clicking on too much idiocracy you should be safe... if you have an antivirus and a firewall installed and a customisable browser like firefox to block pop-ups/scripts etc?

If it is more like the latter then a generally educated user shouldn't be worried.... but I know most users aren't (as I've had many an experience cleaning up other people's computers... sigggghhhhh... the wonders of malware/worms/trojans)....

Think it would be enlightening to see the actual types of exploits over the years that have been utilised and whether they could have been instigated through normal unobtrusive, un-extraordinary means as opposed to third-party app installation or more involved methods..

[LazyEvul]

Based on what you talk about for the App Store and it's apps (or maybe within the OS itself), there doesn't seem to be the ability to prevent permissions from being revoked by the user. That may either be a function of the filtering process of apps that get submitted to the App Store or the SDK just doesn't allow the developer to prevent revoking permissions.

I'm quite certain it's a function of the operating system. Barring an exploit, it leaves full control over permissions in the hands of the user. The job of the App Store review process is really to prevent apps abusing those permissions once a user grants them - though this isn't perfect, because we've seen some clever ways to hide this abuse in the past.

However from your explanations the app level control seems to be similar to what most OEM's offer, but iOS even goes further to revoke (at least location) permission from SYSTEM or OS LEVEL processes which is neat. I am not sure how this compares to the Android/Windows Phone platforms. I think it is generally either a binary choice (again at least with the location) of either ON or OFF with the other systems including BBOS. Don't think it gets more fine tuned than that. And that's just my personal opinion based on browsing through settings for CyanogenOS on a Nexus; and Windows Phone 8.1 on a Lumia. Anyone with further information can clarify.

You might be right about this. I've used a lot of different phones across all major platforms, never seen such granular location permission settings before.

Regarding this, how do you tell the 64-bit from the 32-bit iPhones.... as far as I can tell there have been no real marketing or model number differences that I can say would lead me to believe that there wasn't anything other than one fixed version for any release... Or are you referring to generational differences: for e.g. earlier iPhones would be 32-bit whereas later iPhones would be 64-bit?

The iPhone 5s was the first to offer 64-bit, and all of the iPhones launched since then (excluding the 5c) have been 64-bit. As a result, all of the iPhones available from Apple today (6, 6s, SE) are 64-bit. Easiest way to tell is to look for a Touch ID sensor - that requires the Secure Enclave, which is only present on 64-bit processors.

You seem to be quite knowledgeable with regards to the security aspects. Is the implementation of the "Security Enclave" in the 64-bit processor for the storage of the device encryption key different / more advanced / less advanced to how Blackberry implements their security checks? I'll need to update the post above to reflect some of what we talked about here but I'll wait for some of your feedback first whenever you have time. (i'm afraid by the time I finish update the Original Post I may have to write it over again because it'll be outdated.... )

It's similar, at least in principle, to BlackBerry's "root of trust" model, but BlackBerry doesn't really provide enough detail for me to say how different they are. The Secure Enclave is a separate processor, with its own encrypted memory and microkernel, making it largely immune to vulnerabilities within the OS and application processor. BlackBerry claims that the Priv uses "BlackBerry Secure Compound" to deal with similar tasks, but they really don't go into detail about what it is - they just refer to it as a trusted execution environment, which would typically be a step down from the Secure Enclave because it's not quite as specialized or isolated. I used to think BlackBerry might be using a rebranded version of Qualcomm's TrustZone, but the Priv didn't receive fixes for TrustZone vulnerabilities in the last monthly security update, so I'm not sure about that anymore. For BlackBerry 10, the company is even vaguer, just saying that they add an encryption key "to the processor" during manufacturing.

One unique thing the Secure Enclave does is provide hard-wired protection against brute-force attacks on the password - each password attempt is designed to take 80 milliseconds. This can act as a final line of defense if software protections are circumvented through exploits.

I should also clarify that the encryption key isn't actually technically stored in the Secure Enclave. What I meant to say was that the Secure Enclave contains the UID - a unique identifier unknown to Apple that is entangled with your password to create an encryption key. Files on the device have keys stored and encrypted within their metadata. Each individual key can then be unlocked using one of four class keys (each class provides a different kind of access, to put it simply) - all of which are encrypted, stored and managed by the Secure Enclave. That encryption key based on the password + UID is used to encrypt some of these keys.

If you're interested in some more reading, this blog post about the latest Qualcomm TrustZone vulnerability offers a lot of detail on how Android + Qualcomm CPUs typically deal with device encryption, and why it's very broken: https://bits-please.blogspot.ca/2016...ster-keys.html

And here's the iOS Security Guide, which provides a detailed description of how the Secure Enclave works and how device encryption is managed: https://forums.crackberry.com/e?link...token=eAgyh1jb

You can also check out the BlackBerry 10 Security Guide (https://help.blackberry.com/en/bes12...y-Guide-en.pdf) and BlackBerry Priv Security Guide (https://help.blackberry.com/en/secur...y-Guide-en.pdf), but they're sorely lacking in detail.