Hmm maybe so maybe not Re: "Blackphone" said to be "a super-secure nsa-proof"

[coderman]

On Sat, Jan 18, 2014 at 12:16 PM, gwen hastings <gwen at cypherpunks.to> wrote:
> ...
> Now in the secure phone case .. there is NO way to know that you are
> secure against NSA TAO even if ALL source code to the phone apps and the
> base band processor firmware is published.. not even if the VHDL code
> for the IC design is published..
>
> does mean we stop trying and give up?? hell no...think of it as a
> economic problem even classifying enough crypto at realtime speeds for
> capture turns into a major pain the the ass even on Narus boxen.

indeed, useful as a cost deterrent even if fallible.

and of course, it's fun trying to protect against these attacks (e.g.
playing on "Hard Mode").  for some definition of "fun"...



> but all claims of NSA proof are indeed basically somewhat fraudulent as
> its a guarantee that no one checked out the chip design software for
> auto insert logic additions to their cell libraries. And with TAO
> placing teams of engineers its almost a sure bet that the  IC libs are
> contaminated either with active flaws or simply important ones that
> never got reported. And etc ad nauseam from the silicon on out..

the short list of mandatory steps to play the game:

- never mess up!  one mistake can be catastrophic. (this means
developing habits)

- source all hardware through retail outlets paid in cash. (avoid
targeted supply chain inserts)

- review all open source components related to key generation,
management, derivation, zeroisation.  or have someone you trust do so.
(see also: crowd funded TrueCrypt audit)  replace unsatisfactory parts
with better ones. (still using my own rngd; so glad to not have to
roll my own FDE boot and key mgmt anymore!)

- use extensive defense in depth.  Virtualization/Qubes, operating
system DACLs, user space separation, network isolation, offline-only
key management, the list is infinite!

- monitor everything: network traffic pre-encryption, running
processes, system calls, event logs, RF signals, sounds, power
consumption, at the highest granularity possible.  analyze what you
monitor for anomalies and failures. (if you aren't watching, you won't
know when you've caught something interesting, and/or need to harden
some first line defenses)

- custom build critical software components: kernel, crypto libs,
secure applications (ssh,openvpn,etc), high risk browsers, email
clients, chat clients, document viewers. (vast majority of exploits
are tailored for common builds - if you build your own with custom
configuration, suites, supported features, exploitation becomes a
tailored and time consuming effort against your specific system)

- employ camouflage to further thwart attempted attacks and increase
the likelihood they'll be detected.  look like WinXP but be a FreeBSD,
claim to be Firefox with plugins such and such while actually running
hardened chromium, spoof versions and platforms, etc. etc.

- employ userspace entropy collection, hardware entropy sources, and
strong entropy mixing across all applications, always! you may need
libc hooking or dalvik interception to make built-in entropy sources
not suck. (e.g. substrate for Android, LD_PRELOAD, etc.)  entropy is a
lucrative target, hard to verify, and often overlooked - make it a
priority!

- physical security is paramount: evil maid attacks, covert hw
keyloggers, TEMPEST leaking cables. if they get their hands on it, it
is pwned! (this may cramp your lifestyle)

- operational security: don't even know where to begin with this one.
bonus points for getting the fed chick[0] to take a bowl hit ;)



>        gh(who is now finally picking up the python language in a serious
> way)

excellent; i like Python quite a bit for many tasks, and you'll want
to spend a week going through pypy/pip looking at useful modules.


other languages on my short list:
- C/C++ (it's everywhere.  it will remain everywhere.)
- Scheme/Lisp (for the perspective more than utility)
- Ruby/PHP/PERL (good complements to Python. except PHP, which should
be hated and ostracized :)
- Bash/Csh/PowerShell (scripting++)
- Go/C#/Java (you're going to want to know these sooner or later)
what would you add, and why?


best regards,




0. not trying to be a dick, but a dismissive chick label in this
situation intentional.  employing attractive women (or men?) to HUMINT
targets may be par for the social engineering conference course,
 but subterfuge based in sexual wiles == cheap shots and disrespect.

oh how hard i had to work to stifle a chuckle when $fed_chick
explained she was "in desktop security but moving into laptops..."

see also: "beware strangers with candy"


best regards,