Android Call Encryption
Posted 07 April 2014 - 01:58 PM
Got an email on this thread. I got to look at my old statements, look at the results of Snowden leaks, and see how accurate/inaccurate they turned out. My old claims proved true over time. The NSA leaked TAO catalog showed they attack BIOS, peripheral firmware, emanations, crypto, base station layer, device drivers, privileged software, and regular apps. They also subvert the hell out of things at supplier level with bribes, coercion and infiltration. My requirement for high assurance (EAL6-7) at every layer, component, and interaction with independent evaluation by mutually suspicious parties and secure distribution is indeed necessary to stop (or slow) a TLA. Funny thing most projects reacting to NSA leaks are aiming for *much* less security or trusting complex lower layers already hacked. Such is a fool's game of building foundations on quicksand.
I talked to Frank Rieger, Cryptophone co-founder, on Schneier's blog years ago. I told him his phone was trivially hackable by an NSA type opponent despite his OS hardening because of lower layers and insecure architecture. I said he also couldn't prove to his users he didn't backdoor it, which had huge precedents (eg Crypto AG, Skype). As such, I told him he'd need ground up redesign to secure the architecture with independent evaluation that publishes the hash of the image, including software/firmware updates. Over time, they've added Android to the TCB and a mere "baseband firewall" for IO issues. (Rolls eyes...) My solution, which addressed various layers, had enough hardware to fill a brief case lol. At least the headset and keypad were light! A small, integrated version would require a custom ASIC with each component likely done fresh. ASIC's with proven components often cost $15-30 million to develop (mask alone is $2mil). Such is the cost and complexity of a nearly NSA-proof cell phone. Virtually every "secure" cellphone on the market shortcuts by using COTS, so my heuristic says they're *definitely* insecure. Secured cellphone would be bulky, more expensive than Cryptophone, subject to patent lawsuits, and probably still be vulnerable for EMSEC attacks. See General Dynamic's Sectera Edge for what it would look like far as size and trusted path interface.
Situation looks dire for mobile COMSEC. My current scheme is to build a portable machine that other things, eg laptop or cell phone, can interface to. The common hardware uses best of breed security engineering to implement a MILS security model. The interfaces layer has much functionality, esp crypto, sealed in the hardware. So, the person pulls out their tiny smartphone, but it's really another device doing the work. The phone just has to securely connect to it, relay IO, and display something on a screen. Security requirements for that device should be small enough to allow high robustness. The *other* device will be bulkier and more complex, but it affords extra chips I need to use proven methods* maybe even in reusable way. Main board can be in briefcase, backpack, conference table, desk, car, etc. Whole thing would be expensive with the assurance activities and hardware. Hopefully, it can be under $10k. (Original briefcase model with medium assurance components & high assurance security kernel cost a few grand in hardware alone.)
* Proven methods for nearly impenetrable systems include tagged memory, capabilities, smart IO processors with IOMMU, interrupt-less designs, non-writable firmware, small TCB, and default-deny control flow with access table for permissible function calls. Each of these already exist in a real product or design, past or present. Good news is much of it existed in old systems so it's consistent with my recent strategy of building modern system out of ultra-old shit to prevent patent-related takedown. Look up Burrough's B5000 libraries/HLLcode, IBM System/38 whole architecture, Hydra/CAP capability machines, GECOS's firmware approach, Intel's i432/i960MX designs, and so on. These each have some brilliant design decisions that make modern architecture look like shit from a security standpoint. However, the memory confidentiality and integrity schemes that prevent common physical attacks seem to be a modern invention almost certainly covered by patents. My first system will therefore assume physical security & trusted admin while aiming to defeat all remote, software or interface level attacks. Next system will do other stuff.
My post on Schneier listing much of the best current security tech in case anyone wants to work on *real* security like the people in the paper (and myself) are doing:
I hope NSA leaks inspire more work on *real* full-system security instead of all the mental masturbation of finding 0-days, writing tons of unsafe code (eg C/C++) and putting more band-aid's on architectures not designed for security (eg UNIX model). But, hey, there's still billions to be made pushing or compromising bullshit security so why not.
Posted 03 June 2014 - 04:16 AM
NSA secure is actually "privacy from Microsft, Google and the various encryption standard capture/decrypt on the wire" (is it still Phoenix Global that does the backend stuff or did they change their name?).
dropping through an insecure device somewhere along the line is unavoidable (short of your own hardware hardened darknet), so you just have to make sure the data is secured before it gets there. Fankly anything is better than the default situation which is anything and everything you put into google/microsoft software (or any of the new big providers) going straight for processing.
My point is the market is there, and it doesn't have to cost a small fortune for protection from the most ubiquitous evesdropping (anything that "breaks" the standard decryption protocols is enough).
Edited by mSparks, 03 June 2014 - 07:03 AM.
BinRev is hosted by the great people at Lunarpages!