mentioned in issue ops#4 (closed)

The Snowden & Bunnie design has been mentioned on Schneier's high-profile security blog: https://www.schneier.com/blog/archives/2016/07/detecting_when_.html

More resources from @mad_dev :

• https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People
• http://www.hardwareluxx.com/index.php/news/consumer-electronics/cellphones/33693-umts-encryption-hacked.html
• https://news.ycombinator.com/item?id=10333354

Milestone changed to URGENT

to exploit momentum we need to react on the actuality of the Snowden thing topic swiftly

I made this list of possible items to include in the PR before the respective meeting. Supposedly it's linked somewhere, but I don't see it: https://neo900.org/stuff/paste/Vietu8ei.txt

Two remarks:

• forget to mention NFC in "other RF". The RF chip is "dumb" and we have control (own firmware, field-replaceable) over the MCU controlling it, which we consider sufficient for ensuring nothing untoward can happen there.
• I mentioned this in IRC already: we should be careful if attacking the theoretical nature of the Snowden+Bunnie design, given that we don't have any running hardware, let alone a proper analysis of its behaviour either. In particular, we have yet to establish and evaluate profiles (combining inputs from current sensing, antenna sensing, and activity on the communication interfaces between modem and CPU) that can tell suspect from "normal" behaviour.

[added by JR]

• definitions:
  • CPU = application processor (OMAP), the thing that runs Maemo, Android, ..., UI, middleware, apps, ...
  • modem = GSM/UMTS/LTE, and any integrated blocks (e.g., GPS/GNSS)
• main mainly distrust the modem, due to
  • lack of transparency (completely closed)
  • high degree of autonomy (complete system, directly on battery)
  • history of use as attack vector [silent SMS, more ?]
• defenses
  • constrain modem ability to infiltrate CPU
  • limit modem access to sensors
  • monitor RF use (e.g., [location update])
  • monitor activity, for multi-stage attacks for deferred action (e.g., record conversation now, send later [reference ?]
• protecting the "trusted" CPU
  • no peripherals share memory with CPU, especially not modem [[ edit by JR ] reference to the typical bad modern design with modem sharing CPU hw resources] [reference to our modem sandboxing, ccc15 talk slides p15ff]
  • Free and open operating system, UI, core applications
  • no binary drivers required [ edit by JR ] IOW every single instruction the APE linux CPU executes is from a FOSS line of code the user can review and modify
• monitoring
  • CPU monitors telephony antenna activity,
  • [ edit by JR ] delete this, inbound we can't monitor, we can just make sure a strong aka TX signal is actually from our modem and not another transmitter 5cm away - something S&B can't do even if they go for direct RF monitoring of the antenna inbound and outbound
  • CPU monitors modem current consumption (for deferred action)
  • CPU monitors GPS amplifier activation
  • [ edit by JR ] CPU monitors audio/microphone interface activation
  • CPU monitors several (almost all) signal pins of modem
• interdiction
  • CPU can cut power to the modem
  • CPU can override GPS [ edit by JR ] antenna ((!amplifier)) activation
• response
  • CPU decides what is suspicious and what not (note: we have done no such profiling yet, all is based on theory)[ edit by JR ] not entirely, I did my fair share of monitoring using stndard phones like Nokia 2110 plus monitormode and external detectors for TX activity, over several days during last 10 years
  • user decides how to respon se d to perceived threats, especially
  • user decide d s whether to reveal detection of possible threat [ edit by JR ] by actually taking technical counter measures like powering down modem
• other RF
  • we trust that being able to deny firmware is enough to tame WLAN/BT. Is this really sufficient ? [ edit by JR ] what is the attack vector / threat?
  • we trust that not enabling / holding in reset is sufficient for FM RX/TX (with RDS). Is this enough ? [ edit by JR ] what is the attack vector / threat?
  • [ edit by JR ] NFC?

The World's Most Secure Android Smartphone

"You wouldn't put money in a bank that didn't lock its safe."

Hmm, no.

"Or leave the doors of your home unlocked at night."

Hmm, yes, I do it all the time. Where do you live?

http://us.blackberry.com/smartphones/dtek50-by-blackberry/overview.html

Review

http://seekingalpha.com/article/3993997-blackberrys-new-dtek50-smartphone-secure-apples-iphone?page=5

What I see here are a lot of good features that are already available on other smartphones, like Apple's iPhone.

BlackBerry's DTEK50 looks to be a reasonable Android smartphone in an ocean of reasonable Android Smartphones. But with such a weak security claim, I don't see this newest smartphone changing BlackBerry's fortunes, and in fact leading to sharp criticisms within the security community.

Apple Security Guide

Every iOS device has a dedicated AES 256 crypto engine built into the DMA path between the flash storage and main system memory, making file encryption highly efficient.

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

mentioned in issue #5 (closed)

bumping tagged URGENT #3 (comment 7426)

I made this list of possible items to include in the PR before the respective meeting. Supposedly it's linked somewhere, but I don't see it: https://neo900.org/stuff/paste/deeji4Ri <

the mime type is "bin" in FF and "unknown" in konqueror, both browsers don't offer to view the content, FF offers "save file | cancel", konqueror offers "open with..." - please fix mimetypes/filetypes in https://neo900.org/stuff/paste/ * resp make sure uploaded files have a useful filetype

[edit] appended text of that file to werner's post 2 up

I have no direct control over the MIME type, but npaste now appends .txt if there is no other extension. Re-pasted https://neo900.org/stuff/paste/deeji4Ri as https://neo900.org/stuff/paste/Vietu8ei.txt

mentioned in issue ops#8 (closed)

I read most of the Bunnie & Snowden article , and the main question to answer IMO is:

how does Neo900 relate to the concept of direct introspection , as introduced by this paper?

Beyond studying how the Neo900 design makes it a lot more interesting than just giving awareness (what is awareness worth when artillery is shooting at you because they got your location from your phone?), it's important to expand on the idea.

Can we consider that the Neo900 features (power segregation, rogue chip separation, monitoring) constitute direct introspection , and in what measure our implementation is safe from software compromise (think: spearphishing, AKA user-activated malware)? The latter is important, because of the physical separation between the device (considered compromised) and the "introspection engine". Whatever we say around the article, these are the priority questions to answer. Also: selfie-cam shutter?

I made an initial plan with lots of notes and stuff, but it would be a waste of time for you to review it now, so you have to wait a bit :)

Then secondary questions spawn from Neo900 design directly related to "direct introspection", feature by feature (need to review one by one, to establish a catalog of "direct introspection" in Neo900 vs. proposed iPhone6 case design).

Re: #3 (comment 7400)

Looks like a clever design. Of course, it has to be outside the device; otherwise, it could be compromised along with the device. -- Bruce Schneier

Trade-off: external & awareness-only vs. internal & prevention

What about the combination of both internal and external?

The techniques developed in this work should also be applicable to other makes and models of phones. Pervasive deployment of radio introspection techniques could be assisted with minimal cooperation of system vendors. By grouping radio control test points together, leaving them exposed, and publishing a terse description of each test point , direct introspection engines can be more rapidly deployed and retrofitted into future smartphones.

@wpwrak : what is the status of the highlighted part in Neo900?

Looks like a clever design. Of course, it has to be outside the device; otherwise, it could be compromised along with the device. -- Bruce Schneier

here Schneier fails - only applies for 99% of devices available today which don't put user into 100% control over the APE

[2016-08-11 Thu 00:48:15] \\<wpwrak> our trust model is a bit different. we do trust the CPU, since it is / can be running only open software

for clarity we should add: ... and our CPU cannot get compromised by the modem since modem has no access - unlike all shared-RAM devices out there

By grouping radio control test points together, leaving them exposed, and publishing a terse description of each test point

this is a red herring too, since it depends on trust into manufs' description of the semantics and function of those testpoints. Only an open design like Neo900 can cope with that, and we don't need external testpoints since our (considered clean, since under user control) APE (aka Linux CPU) already has full control of all those "virtual" testpoints. Heck we have 10 times the amount of "testpoints" than iPhone, and each single one of them is a 50 times more useful since designed to serve for exactly this monitoring/introspection purpose

IOW we do to modem what Snowden&Bunnie (try to) do to iPhone. Just we do it genuinely and thus way more effective and reliable. S&B approach to antenna switch bus is conceptual flawed anyway, as I already elaborated upon (not to get pusblished that harsh please)

Maybe like this: ""it is hypothesized that we see activity on antenna switch bus when device starts sending"" is most likely a fallacy. Anyway it's not really backed up by any research or cogent technical rationale and thus not (yet?) verifiable as a trusted tamper-proof means to detect all attacks that make the device send. Neo900 has true SWVR metering instead, among a plethora of other detectors, which will obviously detect all modem transmissions

[hellekin] Can we consider that the Neo900 features (power segregation, rogue chip separation, monitoring) constitute direct introspection, and in what measure our implementation is safe from software compromise (think: spearphishing, AKA user-activated malware)?

yes, we do much more than 'direct introspection', we do introspection by dedicated means *), plus sandboxing. *):our introspection is a foundation design consideration, not an afterthought like S&B approach. We employ dedicated hardware only for that purpose

user-activated malware

beyond scope of Neo900 design, since it's a software issue and all we can say about this is: unlike any other known recent mobile phone, Neo900 allows user 100% choice and control (aka "freedom") about what (OS, apps) they run on Neo900. We don't intend to, and we cannot control this, however we recommend FOSS OS based on linux with 100% open source and FOSS-typical community audit. When user decides to install malware, there's nothing we can do about it, no matter what. No way to deal with this on a hardware (or FOSS software) level.

history of use as attack vector [silent SMS, more ?]

of course more :-) - The [ #9 (closed) ASN.1 vulnerability] that renders a major fraction of all existing smartphones owned by anybody capable to run such attack against a phone with the defective ASN.1 lib

Plus there's still the official OTA firmware update many modem manufs advertise as a desirable feature

mentioned in issue ops#10

Reference Apple spyware attack

CVE-2016-4655 to CVE-2016-4657

mentioned in issue ops#11 (closed)

Added PR label

Geolocation Techniques

A combination of https://en.wikipedia.org/wiki/FDOA and https://en.wikipedia.org/wiki/TDOA may have been used by the Syrian military to passively locate Colvin's transmitter with enough precision as to send an informant to confirm her presence. (?) Another point is that these measurements would have been done during transmission , which means the introspection engine wouldn't have said a thing about abnormal behavior of the radio systems of her satellite phone (i.e., not an iPhone .)

http://en.wikipedia.org/wiki/U-TDOA Yes, this is also possible with SATs (or Location Measurement Units (LMUs) mounted to airplanes), it basically works exactly opposite way to usual GPS then

Sweet. Here's an updated version. There's still some work, but I found proof with the treatment of the Marie Colvin case, than not only it's such a bad move to take it as an example in this case, but also that Micah Lee "reads" what he likes for the sake of his argument. This article is going to throw a bomb in the water, and will require high profile response (if we can reach the right people).

snowden-bunnie.md

we trust that being able to deny firmware is enough to tame WLAN/BT. Is this really sufficient ? [edit by JR] what is the attack vector / threat?

The attack vector is a remote firmware update (e.g., by the operator, using properly signed updates although they contain state-level agency malware in it). In Neo900, "vendor firmware updates" are non-existent I suppose.

Airplane Mode

Objectives:

• question the validity of the "Airplane Mode" switch as a manner to observe suspect radio activity on the iPhone 6 (GPS not affected, independent (software) switches for Wifi and BT, etc. => possibility of silent-gathering-first-dataleak-later attack?)
• question the claim of adaptability of the Direct Radio Introspection to various devices (variability of "Airplane Mode", regulatory vs. technical, example of Cryptophone's device-specific reverse-engineering of the Galaxy S3 baseband processor => cost of 'adaptation' skyrockets as the DRI approach is not invariant across devices [if at all possible])
• conclude with the solidity of the Neo900 free-hardware-based approach

Resources

• FAA announcement and Portable Electronic Device portal
• "Airplane Mode" at Apple (does not mention GPS)
• https://en.wikipedia.org/wiki/Airplane_mode