Comments

ThothJune 30, 2014 9:35 AM

Limited feature Android phone would yield better security by restricting choices to a set of applications. I wonder if the phones are tamper resistant ?

A good to have feature for tamper resistant secure devices that carry batteries with them is to have a passive tamper detection system that requires minimal battery power even when the phone is switched off.

Mark J. BlairJune 30, 2014 9:53 AM

Maybe I'm just excessively paranoid, but the lack of physical shutters over camera lenses on phones, tablets and laptops irks me. Since I rarely use the camera in my MacBook Air, I simply put a piece of opaque tape over its camera. That wouldn't be a very practical solution if I actually used the camera, though.

Rufo guerreschiJune 30, 2014 10:08 AM

It would be good to differentiate a 1 day journalist end-user review, with a couple of attack simulations, from a proper review of a device that makes such claims. Such review would take complete verifiability and extreme actual verification of all potentially-critical sw, firmware and hw involved, in addition to hw design and manufacturing process.
The journalist review is very bad disinformation, as it does not even inform users if scientific assessment of its security from advanced threat actors is even possible, by telling them at least what hw, sw or firmware source code or documentation is or is not currently available for independent review without NDA.

mj12June 30, 2014 10:19 AM

@Mark


if I actually used the camera, though.

There are plastic/cardboard covers that are like |¯|. Stuff it on the lid, move aside when you need the camera.

simulJune 30, 2014 10:46 AM

The blobbed Android's Linux kernel is NOT secure, no matter how the phone is called...

Rufo guerreschiJune 30, 2014 10:51 AM

The Ars Technical "review" concludes that Blackphone "lives to its hype". Gigaom David Meyer follows thru uncritically. No major security tech blog, including this one, even asks what hw and sw info is or isn't reviewable.

On the other side, 90% of active comments on an article on Engadget provide a few of the many reasons the product is a total scam or that we cannot have a clue if it is.

If most readers see things journalist don't, we clearly have a mainstream security/privacy tech media problem. Such bloggers do not know nearly enough AND/OR are afraid to go out on the "range of acceptable opinions" AND/OR are passive to other pressures.

Until we'll have better mainstream security media, there will never be a market for adequate privacy solutions, as they will not be differentiated in their assurance levels from unsafe or even unverifiable solutions like Blackphones.
We can't rely on such Media problem to change that much. There should therefore be a standard set, managed by extremely competent and ethical entities, that enable end users to differentiate among solutions.

DBJune 30, 2014 11:03 AM

One of the main features of the Blackphone is a limited time Spideroak subscription, together with the android app for it. See the Ars Technica review of Spideroak.

It purports to be a "zero knowledge" backup, where they store your data encrypted, and don't ever even have the keys... yet... if you look at the fine print... they DO HAVE YOUR KEYS.... !!! This totally pisses me off beyond all measure!!! Here's the fine print: (click here, scroll down to the orange section that is titled "How Mobile Works With SpiderOak’s ‘Zero-Knowledge’ Policy")

Here's the deal: when accessing your data via the SpiderOak website or on a mobile device, you must enter your password. The password will then exist in the SpiderOak server memory for the duration of your browsing session. For this amount of time, your password is stored in encrypted memory and never written to an unencrypted disk. The moment your browsing session ends, your password is destroyed and no further trace is left.

Obviously, technically speaking, they're using a web-based API for mobile, instead of native phone-based end to end encryption within the phone app itself like the desktop app does. After reading that, I got totally turned off from the Blackphone altogether. They can't even bother to encrypt things end to end on the phone itself, even when their big advertising point is that they do... I mean, what the heck... Smart phones are plenty powerful enough to do real end to end encryption, they obviously haven't learned from Lavabit have they...

SimonJune 30, 2014 11:16 AM

Seems like a ...bundle of stuff, not as much like a singularly unique product.

I wish them the best. Think good crypto is hard? Good product design and development is harder.

DanielJune 30, 2014 11:29 AM

"Think good crypto is hard? Good product design and development is harder."

And convincing people that there isn't a hidden back door put in the design by the nice and friendly folks of some government agency is the hardest of all.

AnuraJune 30, 2014 11:48 AM

I think it's dangerous to advertise this as a secure, private phone, since we know for a fact that unless you actually use the apps like silent circle then your calls, your text messages, etc. do *not* provide end-to-end security. On top of that, it's still a phone that you can receive calls and text messages on, and therefore your movements can be tracked.

So at best it's somewhat secure/private, if you know the caveats and use it properly, but it's unverifiable so it might not even be somewhat secure/private.

AlexJune 30, 2014 12:48 PM

If I own a Blackphone and my mate who I am talking to has a normal phone, how safe the conversation is? Just a marketing stuff, there is no such thing as a secure phone.

DBJune 30, 2014 12:56 PM

To be fair, I think it's good that people are at least trying to be more secure than before... I think it's good that security is at least on people's minds... And so in that respect, I applaud the blackphone...

But the entire industry has been in such a horrible mess for so many decades, that you don't have to be very good AT ALL to be way better.... and that's the situation we're seeing here.

NobodySpecialJune 30, 2014 2:00 PM

@Mark J. Blair cameras are a surprising feature for a phone intended to be sold to secret squirrels. Even the commercial labs I visit have a "no cameras" rule

stimoceiverJune 30, 2014 2:36 PM

until, a poem, by stimoceiver.

until,
until I can verify the entire baseband architecture of this device using x-ray diffraction to search for dopant-based vulnerabilities in silicon,
until I can catalog and verify every "hidden" baseband-side software, firmware, or configuration update function that baseband chipset might contain,
until I can verify every spectral emission, every crest and trough, every arc-second of phase shift, of the entire GSM constellation of this phone, along with bluetooth and WIFI signals, and anything else the phone emits, in a RF shielded cleanroom as well as in the real world, with an eye towards the identification of steganographically encoded "store and forward" traffic bursts,

I trust nothing.

Guess its back to tin cans and string for me.

DBJune 30, 2014 4:26 PM

@ stimoceiver

Or just self-censure until all that... assume everything you say and do is recorded in a big white book in the sky for all eternity and will be used against you in a court of law. Christians have been doing it for millennia, you can too. :)

TimJune 30, 2014 4:31 PM

Am I the only one who is a bit paranoid that the phone is advertised on a Chinese web site?

renkeJune 30, 2014 5:15 PM

Tim: I'm more comfortable with Chinese spying on me than domestic one. A Chinese agency trying to hunt me down would have some problems extracting me here out of Europe - this would be different for my country's government (or allies).

EldoranJune 30, 2014 6:52 PM

The blackphone basically brings the phone about on par what was state of the art on a PC 10 years ago.
Unfortunately that means is mostly unable to prevent attacks used by the NSA. Even IF everything was correctly implemented. The VPN for example merely moves some of the data from google to silent circle.
Some gaping holes are addressed, but safe is something else. Like the windows firewall and virus scanner are better than nothing, but are quite ineffective against spearfishing or any determined adversary.

Nick PJune 30, 2014 7:07 PM

@ DB

re SpiderOak

I actually like what I saw. They mainly market it for desktop use, are honest about how it works on mobile and recommend only using desktop if you want zero knowledge. It's also a huge box on the page with colors and contrast that stand out. The only other part they emphasize that much is the "try it it's free" section. It's also in their Engineering section that explains how their cryptography works. So, all in all, much more open and honest than how most sites do it.

"Obviously, technically speaking, they're using a web-based API for mobile, instead of native phone-based end to end encryption within the phone app itself like the desktop app does. After reading that, I got totally turned off from the Blackphone altogether."

Were you meaning to say SpiderOak in this one? Just making sure I'm following the post correctly. If so, I agree that they should be able to do it the good way on mobile, too. They might be trying to keep their development costs down as they're still a small company. Many companies only do one or two mobile platforms for this very reason. This would give a temporary mobile solution until better ones could be developed. Or they're lazy. Or it's a backdoor. Who knows...

" that you don't have to be very good AT ALL to be way better"

That's so true that it was my business model for a while lol.

@ renke

I agree so long as your opponents are domestic and you don't have anything for the Chinese to steal or use as leverage. The same goes for other countries.

shibumiJune 30, 2014 7:45 PM

Chinese?

.ch is and always has been (since Jon Postel gave it to them)Switzerland.
or am I missing something here.

MattJune 30, 2014 8:33 PM

It has 'secure' in its name. So it must be good. We've all believed that before and it's been true. Right?

ThothJune 30, 2014 9:12 PM

If this phone were to be compared to all the other Android phones, it's definitely more secure than the others outright. But if you are looking from the OS being used, it's Android and for the critical blobs in Android, you need a major make over or simply use or make another phone OS which for a small company, it's not viable. For their budget, I am guessing they don't have much options to choose from.

What they could have done is simply open source their PrivatOS but that may not always be viable for a business.

In simple, what they could have done better and done more is simply to open up their specifications and designs but again they are running a business and it's not viable.

There is no mention of tamper resistance which is a worrying thing and there is no secure cryptographic module (internal HSM/Crypto chip) to handle cryptographic operations and manage cryptographic keys. I wouldn't mind paying more if it is tamper resistant and has an in-built trusted chip platform for crypto operations and key security.

Can this phone really meet security standards ? If we look from the industry's point of view, it may not meet FIPS-140-3 standards as exfiltration of keys and secrets would be trivial.

What is required is a community approved design standards and criteria (base blueprint) for a secure device and we are badly lacking one. Everyone's coming up with their own designs and claiming it's secure with very little proper analysis and research before launching off their "secure products". What we could do better is come up with a base blueprint for these sort of products.

Nick PJune 30, 2014 9:58 PM

@ Thoth

The common standard or blueprint idea is a good one. This is the intent of Common Criteria's Protection Profiles. There is one for mobile devices that covers many use cases, threats, and countermeasures.

https://www.commoncriteriaportal.org/files/ppfiles/PP_MD_V1.0.pdf

A PP like this would be a start. Of course, I prefer to do the technical risk analysis using my framework that works hardware up, piece by piece. Each link must be justifiably strong against common and likely classes of attack. The combination of the right features, very decomposed design, and component analysis should make for a strong system.

ThothJune 30, 2014 10:30 PM

@Nick P
The document seems to be more focused on enterprise (which is good). I think more security have to be done from an individual level as well. More work on secure computing needs to be researched and done and more device makers need to be more aware of security implications and their designs.

DBJuly 1, 2014 12:19 AM

@Nick P

"Were you meaning to say SpiderOak in this one?"

A basic Blackphone includes apps that are supposed to be well vetted and safe... but one of the major apps (spideroak) is totally unsafe to use on blackphone in the exact same way that lavabit was unsafe to use. Additionally, it's hard to find out about this, from the perspective of a prospective blackphone customer!!! Try finding the link to the (admittedly large stand-out print) "small print" page and you'll see what I mean. uh... what? what's the disconnect here? false advertising a bit? That's why I was faulting mainly blackphone in that sentence... but really it's both, yes. And you're right that spideroak mainly promotes their desktop app and has a warning on the others to their credit (only partial credit though, since they have no excuse not to do real end to end encryption on smart phones)...

Again... yes, it's way way better in many ways... but still has a loooong ways to go before it even does much good really so what's the point...

@Tim
.ch = switzerland
.cn = china
the two look similar but are not the same :)

JensJuly 1, 2014 12:31 AM

So, a Phone of an US company, using web services from other US companies whose servers are quite surely located in the US is marketed as "privacy friendly". Am I the only one who finds this a bit dull after the last year of NSA spying news?
Also, saying the phone is "secure" and "privacy-friendly" just by looking at its OS apps and used web services is just stupid. It's true that the custom android version is more privacy friendly than a normal android, but that is not where the problems for privacy are. App control is something you can achieve on a normal android with additional apps. From my point of view, the biggest thread to privacy is the part, which you can not control: backdoors and ultimately the baseband with its shitty own OS which is usually full of security holes (I guess for a reason).
Until someone shows, that this is also "better" than on normal phones, all the "privacy" statements are just marketing bs for me.

JacobJuly 1, 2014 12:57 AM

Regardless all the hype about the phone, I think that the following quote correctly sums it up:

Toby Weir-Jones, Blackphone GM, has said: “We’ve never made the claim we’re offering an NSA-proof device, but we are offering a tool that makes a huge difference to someone who’s using no privacy tools at all.”

Mike the goat (horn equipped)July 1, 2014 2:07 AM

Wow, this device is a comprehensive fail and I believe previous posters have done a more eloquent job at describing its inadequacies than I could, but felt I had to comment on just how disappointed I was as the press really made it sound like it was a real step forward.

WaelJuly 1, 2014 2:30 AM

@Mike the goat (horn equipped),

Wow, this device is a comprehensive fail...
Let's talk about why this device is a failure -- the high level reasons :)

WaelJuly 1, 2014 3:56 AM

Star-date, supplementary... Continuing our mission into planet C-v-P...

Had to shorten it significantly so it doesn't bore you… We’ll probably discuss other aspects as opportunities arise…

When we to talk about "End-to-End” security as a means of “protection”, we tend to forget that “End-to-End” security is only valid if the termination points are trusted. Let’s agree that “trusted” means functions as expected. The advertised functionality is the truth, the whole truth, and nothing but the truth, so help you… So we must have the means or ability to validate and assure ourselves that the end points are trustworthy. This is not an easy task to accomplish for several reasons, not least of which is “Lack of Control”.

Take an example of the need to send “confidential messages” between two people; person A and person B. To make the problem simple (as in short), let's (or is it let us?) assume the key exchange took place in a “secure manner”. A and B have a secure key they use properly to encipher the text. At the “paper” level, the protocol is solid — nothing more efficient than brute force is possible. Now how do we know side channels don't exist which cause the “shared secret” to be shared with person C? If person C gets hold of the shared secret, then game over. There goes your “End-to-End” security. Worse yet, A and B have no means of detecting the shared secret is available to others — they are none-the-wiser.

One way to achieve the desired confidentiality is to “compensate” for the lack of control, by taking some control over a crucial component. The high level principles applied here would be:

  • Separation of domains
  • Segregation of roles
  • Trusted “compartmentalized” TCB
  • Total assured control on key components.

This means that no one but the owner has control of this “critical” element. Before talking about a possible implementations to secure the above SMS “use case”, the problem needs to be clarified, so the solution can be vetted:

Problem Statement:

  • Two parties (A and B) need to communicate via SMS in a confidential manner
  • Confidential means no one other than the two parties can decipher (or de-steganogriphise) the message
Constraints:
  • The users have no execlusive control over the smart phone, meaning:
    • Carrier can update it any time they like
    • User has little to no control on what happens at the low levels of the stack (below kernel), or separate firmware running on CPUs, such as the modem.
    • Chip manufacturer may introduce back doors
    • There are third party solutions that are integrated in the ROM image of the smart phone and are not easy to detect, let alone disable. And if disabled, the carrier can detect that, and deprive the phone from service, or update the phone with a new image either over the air, or other mechanisms, for example a backup persistent image that reinstalls the “spyware”.
Possible Solution:
I talked about what “security” means previously — so let’s see the elements that affect the “security of the device”
  • Total assured Control
  • Complete Awareness
  • Ease of use
  • Owner

A and B are the owners.

  • Do they have “total assured control” of the device? NO!
  • Do they have “Complete Awareness” of what goes on the device? NO!
Skip "ease of use" for this discussion — it’s not relevant at this point yet.
Solution?
Deprive your adversary of the two weapons they have:
  1. Control
  2. Hidden “backdoors” — since we can’t have “Complete Awareness”

How do we do that?
For 1, we “think” the phone has no secure I/O mechanism. So we need to create another component that “We” as an owner have complete control over. Create a small piece of hardware that holds the encryption algorithm — a good one, with possible use of One Time Pads. This piece of hardware / software will connect to the smart phone over a channel. It could be USB, it could be BlueTooth, Peer-to peer WiFi, etc… The functionality would be as follows:
This gadget will be the input / output device and the encryption oracle of sorts. The smart phone will only act as the transport channel, and it’s not to be trusted! Person “A” types a message on the gadget, gadget encrypts the message with the shared key — this is high level, you’d want to use a derived key of the shared secret, and add some mechanisms for PFS (Perfect Forward Secrecy,) but this is an “Algorithm” problem in reality, and has some implementation dependancies. When person B receives the encrypted message on the smart phone, the other gadget takes the encrypted message and decrypts it, then displays it on the gadget’s screen — not the smart phone screen.

What was achieved is the following:
No matter how much control your adversary has, they cannot decrypt the message. They have no control over your gadget — It will not accept any software updates, no one aside from the owner can update it’s software. No one can install malware on it or introduce a backdoor, vulnerability, etc…
This was the technical part, and is relatively easy to develop. A second iteration could include such functionality within the phone itself, and a physical switch will have to detach the keyboard and the screen from the main OS running on the smart phone (Castle, Prison, gates, Warden.) This will be less trusted, but if done in a manner that is verifiable by the user, then it’s better than other solutions.
This is one direction where I was going with the C-v-P discussion with @Nick P, and @Clive Robinson.

Now comes the “political part” — which is not so easy to fix:
Suppose this device is developed and some TLA cannot decipher texts going through the network. Do you think they’ll leave it alone? Of course not! I mean what if the “Bad guys DuJour” get a hold of it and start communicating with perfect secrecy? That cannot be allowed either. So the gadget will be outlawed, subverted, manufacturers will be forced to install backdoors, blah blah blah.

So technically, the problem is solvable. Politically, that’s not my area of expertise (as if the technical one is — lol)
@Nick P, @Clive Robinson, anyone interested…
Would like to chat about the “brain cpu” you linked here at some point in time.
I have some debatable, unproven theories to share:

  • Theory: No system is secure if the owner of the system has no exclusive control on the system

  • Theory: No one has complete awareness of the functionality of the system

  • Theory: If you can’t have total assured control of the system (and most definitely, you don’t), then deprive your adversary of the control

  • Theory: If you can't deprive your adversary of control, then divide and conquer: divide control over parties that are not likely to cooperate against you.

  • Theory: If you blindly add security mechanisms and controls, you are likely to miss something

  • Theory: If you wear an attacker’s hat and add mechanisms to defeat known attacks, you are still vulnerable, if not now, then soon.

  • lemma: a better approach is to follow principle-based security mechanisms that are known to defend against classes of attacks.

  • Theory: You really can't hide anything from a state actor. They can get information from other sources.

I have nothing funny to say, short of the above :)

Clive RobinsonJuly 1, 2014 5:03 AM

@ Wael,

If you hunt back on this blog you will find conversations between Nick P, myself and others, on exactly what is needed for such a secure side channel device, with respect to authenticating transactions --not comms channels-- for banking.

The issue I had identified as the most important was that of putting the user into the authentication chain not past the end point of the chain.

That is for the mobile comms the end point is the untrusted phone, but the end of the secure communications/authentication was the screen/keyboard of the tamper evident device. IMPORTANTLY the user is the link between the mobile and the device, not a camera or USB link or any other form of electronic link that could be subverted in some way (which we can discuss later).

The downside of this is to send a message you have to type it in twice --plaintext into device, and ciphertext from device display into phone-- and the recipient once --ciphertext from phone into the device-- all without any error, which is neigh on impossible for the average human.

Back in my original idea I thought of using capatchers as a way of having something easy for humans but difficult for computers to help reduce the typing load/error. This was before cybercrooks started automaticaly passing on the capatchers to sweat shop labour in assia. Which tells you two things, firstly how long ago I came up with the idea, secondly even I'm not perfect when it comes to thinking of all the possible solutions to problems and spotting the threat vectors they might have ;-)

LAIAJuly 1, 2014 5:09 AM

Seems expensive for a phone these days and sold out already. How many did they make......I wonder.

WaelJuly 1, 2014 5:35 AM

@ Clive Robinson,
Yes, of course I hunted back :) I am using this SMS example as an entry point to securing devices :) I am not emphasizing side-channels per se! I am highlighting a methodology, a model, and a different way of looking at the security problem decomposition.

True trusted end points will have to terminate at the brain someday :) And C-v-P will always be your baby ;)
If you meant CAPTCHA, then I'll have to admit I hate that idea! How could you?

SidelobeJuly 1, 2014 6:24 AM

Even if the security is not perfect (or even very good), this device does represent a start. The review taught me a thing or two - I would not have thought of geo-fencing the WiFi radio. Hopefully this device will cause the mainstream manufacturers to start paying more attention to security. Everything that this device does in the name of privacy should be the norm.

As mobile networks evolve, devices like this with over-the-top voice and video apps will be able to take advantage of them without giving up the security.

SasparillaJuly 1, 2014 9:40 AM

Jens, "So, a Phone of an US company, using web services from other US companies whose servers are quite surely located in the US is marketed as "privacy friendly". Am I the only one who finds this a bit dull after the last year of NSA spying news?"

Small point, I believe the company moved its headquarters to Switzerland over this last year, specifically to avoid being in a place where direct interference from U.S. agencies (or their friends) is likely.

NobodySpecialJuly 1, 2014 10:56 AM

@Sasparilla since the companies main customers are likely to be US govt/military/law once Blackberry goes bust. Then they are likely to be under strong commercial pressure to be cooperative with the US govt, wherever their brass plaque is located.

On the other hand if you are the FBI/CIA/DoD/USSS/NSA then your main enemy and the people most likely to be spying on you are the FBI/CIA/DoD/USSS/NSA - so it should get interesting.

FenceJuly 1, 2014 11:18 AM

I think the SpiderOak app is unique to blackphone.

The claim is that it is a special version.

If someone could verify this, and if so, how it is different?

Different in possibly functioning like the desktop app?

Nick PJuly 1, 2014 2:01 PM

@ Wael

Excellent breakdown of the issues. The proposed solution is also similar to my transaction appliance and secure mobile comms device. The designs assume only one component can be trusted. It's built to as high assurance level is affordable. The I/O is carefully mediated. Sensitive input, whether passwords or voice, goes only to the trusted component. The untrusted component receives ciphertext and merely transports it. Yet, I still used strong components for the untrusted layer as attacks on it can still mess up the security by DOS'ing it or creating false alarms that cause user abandoning device for untrustworthy device. So, typically OpenBSD, a Linux with MAC/MIC, or microkernel-style OS for untrusted layers.

I think we can do better, though. One of my years old concepts was a SOC that could be reused in many types of computers: desktop, laptop, cell phone, etc. The SOC is the root of trust. It doesn't trust the disposable peripherals from hard disks to baseband stacks. The user just has to protect their little CPU card. They can use whatever peripherals they want. As I now think about it, this is actually very similar to the smart card use case and security issues. Anyway, the current idea is how to apply this concept to mobile?

The easy answer is to leverage one of my solutions that combine a secure main processor and I/O coprocessor into a System on a Chip (SOC). The main processor has trusted boot, POLA, and integrity protections built-in. The I/0 processor manages all I/O operations, naturally. My modification is that its DMA engine has both an IOMMU limiting each device to specific memory location and applies same protections as main processor during each internal operation. If main processor uses crypto on pages, then I/O subsystem seemlessly decrypts pages if operation is permitted. If main processor tags memory, then I/O subsystem adds predefined tag to incoming I/O data and strips it from outgoing data. One can choose the best mechanism here for the job in the final design.

The software level takes a microkernel-style approach. Every major component might be in its own address space, segments, keyed memory page, whatever. Information flows are blocked by default, with specific information flows authorized by the kernel and hardware rules. The flows can be changed dynamically by certain privileged components consulting a security policy. An insecure call might have data flow from microphone component to communications component. In secure mode, the permitted flow changes so that microphone component can only talk to encryption component and encryption component can send (not receive) data to communications component. A parallel flow handles incoming encrypted data with destination being speaker. This is the model of the separation kernel (eg MILS or SKPP) approach. I've merely ported it to hardware that enforces security protections on incoming processor commands and I/O data. That removes most of hurdles that remained in that otherwise successful model.

The model I've described trusts the ROM, two main cores, and main memory. Main memory can be made untrusted by adding in-line crypto for confidentiality and integrity protection of each page. A direct line between processor cores and extra SRAM might be necessary for key mgmt. Either way, one can have a full phone OS, insecure baseband stack, etc while only trusting a few SOC and software components for security critical functionality. The phones' boards would be designed against the SOC specification so specific models are known to be compatible. They'd be a shell like my old reusable CPU board concept. The chip itself could be built by anyone, sent along a trusted supply chain, and installed manually into the phone. Or you can buy a preloaded phone and run checks against the chip hoping for the best. Various tradeoffs.

The cheapest approach is still that which Wael and I have described: partitioning operation between a trusted and untrusted device, with former handing all sensitive data and being careful to not be attacked by the latter. It's the cheapest approach. It's drawbacks are inconvenience and the fact that it's bulky. My simple Voice over Secure IP solution took up a briefcase. Smallest version was a tiny cube of two card computers. Total solution cost was under $1,000, though, with it maybe getting under $300 today. The real cost comes in the trusted computer as one must be very picky about what is used and it's typically not cheap. A Raspberry Pi or something can be used for untrusted portion. I'm still occasionally working on variations of this to make it more portable/convenient.

Leon WolfesonJuly 1, 2014 2:07 PM

LAIA - Actually the price isn't excessive. A good chunk of the value is the bundled software...

NobodySpecial - Be cheaper and easier for the gov to purchase Blackberry's assets and core servers, and keep running their secure message service...

WaelJuly 1, 2014 2:46 PM

@ Nick P,

I did notice some similarities. Will take me some time to go though the links. Not surprising :)

SasparillaJuly 1, 2014 2:53 PM

I wonder how the Blackphone (this wasn't the release version BTW) would stack up against a Blackberry with BEM (with or without PGP integrated)?

It's obviously a good improvement over stock Android, iOS and WinPhone - but how does it measure up to what you can go out and buy today from Blackberry (and associated BEM service).

VirmalineJuly 1, 2014 5:07 PM

In many of these smartphone security comparisons, security of data at rest usually takes a back seat to discussions about security of data in transit. To me, the former is even more important than the latter. If I was concerned about the security of the data I transmit, I and the people I communicate with would be on a BlackBerry Enterprise Server.

The security of data stored on my smartphone is as good as it gets. I'm on a password protected, encrypted BlackBerry. Unlike many of the other platforms' handsets, a BlackBerry's password cannot be circumvented with readily available Cellebrite UFED equipment, which is already mobilized in some states' police vehicles. The only way to access a password locked BlackBerry's data is by chip-off in a forensics lab, and that itself is risky. Even if a chip-off is successful, and the adversary gains access to my handset's AES encrypted data, he would still be faced with the daunting job of cracking my 32 character complex password. Not gonna happen.

Chris AbbottJuly 1, 2014 8:35 PM

I have a better idea. Get Android source, as well as RedPhone/Silent Circle source, ect (I actually like CSipSimple with the good codecs). Then build them on an air gapped PC running *NIX, and flash a totally blank phone with all of that. Then you could feel a bit more secure about there not being backdoors.

Rufo guerreschiJuly 1, 2014 10:23 PM

@Nick

I totally agree on the need to deal with trust at the SoC level and every critical component on it, for the design and manufacturing.

Otherwise there may very well be very low cost and detectable ways to continuously exfiltrate data through vulnerabilities imposed, purchased or discovered by advanced threat actors in processors and other widely critical components.

Seems impossible with a limited budget but it may be done as long as we set size and power consumption as portable, and we sacrifice hugely on performance and features. You will then use this device in addition and not replacing your ordinary hopeless device.

As in the no-profit User Verified Social Telematics. Similar approach is taking the American Mini Foundry project.

Nick PJuly 2, 2014 1:13 AM

@ Rufo

Having two devices is certainly an easier option for SOC development. The trusted device might even be a modified version of an existing, low-cost, slim phone. The applications it runs have minimal resource usage compared to many smartphone apps. This allows more resources to be used for assurance activities. If code updates are infrequent, the use of company images would make updates easier and support analysis for architectures that figure out all permissible code paths in advance for control flow integrity. Among other things.

Far as cost, I'd leverage existing work wherever possible. There's plenty of projects that have already modified processors for enhanced security. It helps to start with their work. The other lesson I learned from Karger's EAL7 project: use intermediate deliverables to generate funding for long-term project. So, the SOC could be done incrementally by starting with one modification or feature at a time. Each run would generate revenues that fed into (or paid back) the development of the SOC's. The assurance argument would get stronger each time as more holes were closed.

Nick PJuly 2, 2014 1:31 AM

@ Chris Abbott

The result? Subversion at various firmwares and/or plenty 0-days in the source code that isn't written with highest security standards in mind. Android just has too much code in TCB. All the *good* smartphone OS's have this problem. The one's a person can believably protect aren't nearly as fun. ;)

@ Virmaline

Same problem as above. Wael and I are discussing endpoint issues here specifically because the data protections (transit or at rest) don't work if the system is compromised. And there's so many things to compromise. Besides, we know they can break Blackberries because the leaked slides said so. The lay person evaluating security claims should find it educational that public elements of the government talk like it's unbreakable while classified slides say NSA just siphons data off the devices remotely. Quite secure indeed.

WaelJuly 2, 2014 1:51 AM

@ Nick P,

Quite secure indeed...
In someone's eyes it is! Hint: The "someone" is not the "consumer" :)

WaelJuly 2, 2014 2:47 AM

@ Nick P,
I thought I'd read your link before I sleep after being awake for quite sometime... The only comment I have is to reiterate what @Figureitout said:

--Just finished reading just your essay, goddamn! That's a lot...
I can speed read, but not this fast! Another day...

VirmalineJuly 2, 2014 8:40 AM

@Nick P Look, I get it. The NSA spying on Americans, at the very least (not sure if I care about spying on any foreigners), sucks. The thing is where the rubber actually meets the road for most Americans, even the corporate security types and anybody who would post here is when the cop pulls you over for allegedly texting while driving, takes your phone and plugs it into a Cellebrite UFED device to download the "evidence" of your texting before you've had a chance to "destroy" it. Incidentally, he just happens to get everything else on the phone while he's at it for "everybody's safety," of course. That's not gonna happen with a password locked BlackBerry. It's extremely unlikely he would even get meaningful access to the data if he took your password locked, encrypted BlackBerry (on a more serious alleged offense) to the forensics lab, took the memory chip out, and got access that way. If your password is sufficiently strong, the lab wouldn't even get a hash match in the offline attack. For example, when I read the discussions on Forensic Focus Forums, it's clear that the people in that industry are working hard to get mobile device data and to preserve it in a way that it would still be admissible in court. With many devices and users sloppy security protocols, it's not that hard to do. With BlackBerry, they have very little success.

As for the NSA, I'm most disgusted by the level of complicity and cooperation on the part of the carriers we pay, the "service providers" we use (Google, fb, etc.), and the manufacturers with the back doors and compromised hardware. I understand the NSA can grab my transmissions. I somewhat remember seeing the slide you mention and not thinking much of it, because it seemed kind of vague. Are you saying that the NSA has remote access to the data store on my BlackBerry? Also, is a pair of Sectera Edge handsets secure, voice calls and all as is claimed by the manufacturer, or is that compromised at the NSA level also? I would think General Dynamics is certainly seriously compromised.

Nick PJuly 2, 2014 11:58 AM

@ Virmaline

There's a lot of things regular cops can't get into. Solutions of that nature exist for most mainstream phones. The threats I'm mentioning, from subversion to 0-days against phone software, are used by resourceful black hats to get into phones. The NSA slides indicated they could own every type of phone. The group involved typically uses 0-days, subversion, or physical attacks. So, it's one or more of those.

The thing to remember is that this isn't just an NSA thing. NSA mostly buys their 0-days from private parties that produce them by digging into code for the mistakes. There are both black hats and defense contractors doing this. The NSA isn't the only buyer on that market. Our country has over 20 others actively gaining economic intelligence on us, coming after our I.P. and business strategy. They use any method they can from face-to-face elicitation to hacking. The Chinese mostly use hacking and do much 0-day hunting themselves. So, if these mobiles are wide open to this TLA, they might be wide open to one or more of those as well. And, unlike the NSA, there's no debating those organizations are on the attack.

This leads me to ignore software-only claims and look at the security-relevant attributes of the whole phone. This is the attack surface black hats will aim at. No mainstream phone is good in this regard. Funny you mention Sectera as they *might* have the good traits, but it's quite closed so I don't know. That it's NSA certified with plenty of classified technology and limited distribution suggests an NSA backdoor is possible. GD acquired OK Labs whose offerings are commercially available, often inspectable, employed microkernels, and added many useful security features. The chip and firmware levels were still not assured.

Best way to look at smartphone security is that it protects your data from casual or non-resourceful attackers. That does matter as there's plenty of risks there. However, those security options largely can't be trusted to stop attackers who are (a) resourceful and (b) talented. That the product evaluations all max out at stopping "casual or inadvertant attempts to breach security" says plenty. ;) It's why a number of people with plenty to protect simply don't put such data on their phone. Best solution.

Note: I'm glad you mentioned Sectera as following the link led to Apriva Mobile Secure Email solution. I didn't have a review of that one in my files. It's now on the todo list.

Mike the goatJuly 2, 2014 4:59 PM

Wael: okay, I'll bite. a) they are using standard commodity ARM SoCs and cellular radios. We know from experience that, especially in regard to the radio/baseband (which is almost always a closed source binary blob from the likes of Qualcom) are almost certainly subverted. b) their choice of using Android is curious, given we've seen its odd architecture is not conducive to security despite the recent changes in AOSP from 4.x. It is clear that no matter how you dress it up an AOSP based phone isn't really going to be 'secure'. c) most phones have binary drivers for which there is no source released, i.e. for the various sensor modules... I assume this phone is no different and runs a tainted kernel. d) just throwing together a few security related apps does not maketh a secure device.

If running Android applications was some kind of essential feature then I think the Blackberry idea has merit of running each process in a separate emulation layer, but I think the unfortunate truth is that the apps that most people run are likely the cause of information leakage. You only have to run something like Wireshark on a network that has a few Android devices and you'll see how much crud goes backward and forward between cells in people's pockets and, for example, facebook et cetera. I have even seen the FB app send phone contact lists without prompting. Not surprising, but I figured that in 4.2 Android's developers were trying to stop this with AppOps, but mysteriously that disappeared in Kitkat. Okay, yes - there are third party 'privacy' firewalls like XPrivacy, but that's kinda not the point. There are deep architectural issues here.

I don't believe there are any UMTS or LTE chips available that have a completely open baseband. I've heard the rationale - the same crud that was used for years to justify some wireless chipsets being closed source, i.e. atheros ... "These are SDR's- if we release the src, then people might pollute bands they shouldn't" the spiel goes. Assuming that we could get our hands on hardware that isn't subverted (and it's a big assumption) then I would ensure the device ran a completely FOSS stack so there could be some peer review. I would then include some features that I think are sorely lacking; primarily voice encryption that works over a standard switched voice channel. We've seen this with other government grade secure phones and there is no reason we can't do this as well. We need secure key storage, and tamper evidence. In short - we need a lot more than a lightly modified Android based handset with a few custom apps.

DBJuly 2, 2014 5:34 PM

@Fence

Good security is not something you secretly sneak in, bad security is. ;-) so, no mention of the spideroak app being modified to have end to end security means it probably doesn't.

WaelJuly 2, 2014 10:37 PM

@Mike the goat,
Since when do goats bite?
I'll highlight the terms I agree with you on:

  • Closed source binary blob
  • almost certainly subverted
  • most phones have binary drivers for which there is no source released
  • tainted kernel
  • just throwing together a few security related apps does not maketh a secure device.
how much crud goes backward and forward between cells in people's pockets
Imagine the crud you don't see. Try looking at the signaling and data over 3G/4g or LTE. Agree with the rest. By the way, the cellular network stack is complex, so still a lot of crud will go by undetected.

Nick PJuly 3, 2014 12:03 AM

From the same site comes a review of Merkel's new phone:

http://electrospaces.blogspot.com/2013/10/how-secure-is-merkel-phone.html

I'm still not confident in it. At least the article pointed to the company in Germany that makes their only TS-approved equipment. I had never heard of them. The trend with mobiles in Germany isn't much worse than the U.S. where they're using either microkernels + untrustworthy stuff or "security-enhanced" untrustworthy OS's. That sums up recent GD, Boeing, and Samsung offerings. The funny thing is they all know how to do better but there's apparently not enough demand for it among those who know they're getting owned. That's why GD is phasing out Sectera for their Android offering. And DISA has approved connection of these mainstream OS's to the classified networks.

The "Worse is Better" meme still applies. I can't wait to see what passes for military grade security 5-10 years from now.

FigureitoutJuly 3, 2014 12:05 AM

Wael
I can speed read, but not this fast! Another day...
--Quit saying my name you silly so I have to butt in and not feel rude damnit. :p That was when Nick P went crazy w/ his link farm and had his little "Nick's notes" lol.

I'm just at a loss as to how to fix the phones...some f*cking spammers and assclowns w/ no lives call me and troll me sometimes and do the little "*67" trick or I don't know. I know they're skids (uh-oh they may have f*cked up...). They try to act like there's some lawsuit coming my way but it's ridiculous bull and they got scared when I answered the phone. One time I got "fat Tony" calling me, sounding like some mobster spamming my voicemail too. These spammers in Florida are known online but the they aren't shutdown.

And this is a problem b/c we're really reliant on our phones!

ThothJuly 3, 2014 2:43 AM

Proper security would probably require a total rewrite from top down. It is expensive and tedious which most people are unwilling to do. It would also mean that secret subversion must come to light due to open hardware and software designs that the powers that be refuse to give up due to power hunger and greed.

What we can do is to implement a bottom up design where a set of common open standards for hardware and software can be made popular to a point that adoption of proper security becomes transparent.

Nick P and many others have written good open designs and left them on Bruce's comments post. It would be good if these designs can be compiled and proposed.

@Figureitout
Use prepaid lines and if possible have soft block softwares.

WaelJuly 3, 2014 2:47 AM

@

Quit saying my name you silly so I have to butt in and not feel rude
OK, Done! Don't worry about "butting in", it's okay! Don't feel rude either! Coming from you, It's a... compliment :)


Yip -- that was an ultra long link! It'll take a few weeks to go through. @Clive Robinson and @Nick P can write epics -- good ones, though. Educational as well! Not sure who writes more... But @Benni is catching up, I can't read his posts fast enough. By the time I finish one, he already has two more posts stuffed in the pipeline! It's all good...

Are you familiar with Cliff's Notes? You know, the summary texts of big literate pieces? The ones you read the night before the exam you're ill-prepared to take? Well, there is also the Clive's notes. It's the inverse. He takes an input of a few characters and outputs a huge piece of literature. As for @Nick P, I think his epic notes are a good source of entropy :) Come to think of it, @Nick P is an "entropy ranger". Just seed one of his posts into a RNG, and it'll croak.

PS: I left the address "@" empty to comply with your freakin' request :)

secret policeJuly 3, 2014 8:07 AM

I've watched Canada customs plug in BlackBerry phones and it unlocks the screen and provides full access to the device. Data is not protected from governments on BB devices.

Android L has some interesting features, keeping FDE key in TrustZone ARM hardware is one

Nick PJuly 3, 2014 12:01 PM

@ Figureitout, Wael

To be fair to me, the post you two are talking about was a long list of exemplar tech I created as a starting point to the "How do we stop the NSA from hacking us?" question the whole world was demanding an answer for. The adversary is resourceful enough that the answer wasn't going to be short.

(Someone shouts "Just talk face to face with people you vet!")

Ok, well *my* answer wasn't going to be short.

"As for @Nick P, I think his epic notes are a good source of entropy :) Come to think of it, @Nick P is an "entropy ranger". Just seed one of his posts into a RNG, and it'll croak."

Lol. Another guy and I did actually use one of my posts as input to a session key via SHA-2 one time. It was a nice quick fix for a problem we solved more thoroughly shortly after. Another thing I did in that time period was include a hash on blogs with comments. Many thought it was a signature or integrity check, but it was actually a time stamp for my I.P and research data their site was paying to host. ;)

Note: I don't play such games here. Signatures here were the real thing. I just determined the endpoint couldn't be protected with existing methods and that they'd probably get my private key anyway. So, I stopped signing things. Then Snowden leaks came out talking about all these endpoint attacks and crypto bypasses... (sighs)

Mike the goatJuly 4, 2014 4:02 PM

Wael: take it from me (and a hideous experience at a farm when I was about ten) - goats *do* in fact bite. This one must have been carnivorous - it almost took my finger off. And now I am using 'goat' as my handle. Hmm, a shrink would have something to say about that ;-).

I agree with everything you've said. I struggle to think of how a cellphone - one that has to 'play by the rules' ie 3GPP spec, etc. and support mandated 'techonologies' like E911 - could ever possibly be secure in any sense of the word.

FigureitoutJuly 5, 2014 2:13 AM

I left the address "@" empty to comply with your freakin' request :)
Wael
--You silly! Hit up my URL, may be familiar.

Thoth
--Yeah, I'll just tell employers to first email me via PGP after I send them my public key to find my email address in that, then email them a randomized public physical location to receive my phone number which they can then call for an interview only after the secret signal! Lol...spammers and losers will get the number I use on my resume, as well as the email address; to make it easy for HR rather than make them uncomfortable...

Nick P
Then Snowden leaks came out talking about all these endpoint attacks and crypto bypasses... (sighs)
--Yeah about time you sighed for once, I sighed a lot! I'm always out of breath.

Mike the goat (horn equipped)July 5, 2014 6:22 AM

Figureitout: I too use my pgp key as some kind of rudimentary spam control. People can pull my email address off the key servers if necessary.

Unfortunately I did a public records search on a target a few days back and the company involved has clearly leaked my email to the spammers as I have gone from 1-2 UCE/day to 40+.

That said I am a little surprised that the spammers haven't harvested emails from the key servers. It is meant to be confidential but some misconfigured servers allow you to pull the entire keyspace in a series of gzipped tarballs.

FigureitoutJuly 5, 2014 11:25 AM

Mike the goat
--Yeah but do you do that for your resume? For us fortunate to be born in the sh*tty economy and forced to set-up an account for EVERY job we apply to using a different service to even just get a call back for an interview, our information is everywhere...

BTW, lol-worthy...from my yahoo email literally w/in minutes if not in real time:

Hi DHJGFAKJGUWEOUIFYHKJSAKHJSDGFDHJ,

We noticed a login to your Yahoo account (hydralisp62) from an unrecognized device on Sat, Jul 5, 2014 12:15 PM EDT from United States.

Was this you? If so, please disregard the rest of this email.

Hilarious!

Mike the goatJuly 7, 2014 12:25 AM

Figureitout: speaking of resume, I am having similar dilemmas to what you speak of. I'm planning to go back to the US for a couple of years, hopefully the SF Bay area, but in recently working on my resume noticed that I have a few problems. The first one is that a lot of my online work has been done under a variety of aliases and that documenting them will essentially negate the very purpose of having a pseudonymous identity. The second issue is that I worked for a few years on a black project which I am legally not even allowed to document, and that's a real shame as it was some groundbreaking work which I am very proud of. The whole labor market scene has changed considerably in the last ten years, and I've noticed that things like LinkedIn accounts are now pretty much mandatory - something which I will likely have to sign up for reluctantly given I have real concerns about privacy and these social network providers. But I do hope to land something half reasonable somewhere on the west coast - perhaps pen testing, security auditing, etc. The field used to be a lot less competitive. Seems I should perhaps put myself down to speak at a few conferences just to raise my profile a little... I certainly have some good case studies and stories of clients we assisted in the past decade with things as diverse as DDoSing, insider fraud (one of the IT staff installed keyloggers on pretty much all the PCs in the HR dept) and even an insurance company who was compromised using a 0day in their online car insurance quote website (php + vuln + priv esc = local root; local root + cracked /etc/passwd + ssh forwarding = half of their servers pwned). Given the quality of some of these talks lately I think I could come up with something half compelling. ;-)

Regarding your e-mail from Yahoo you quoted (btw: I hope the inclusion of your yahoo ID was intentional), are you suggesting that someone else has been accessing your webmail box?

WaelJuly 7, 2014 12:55 AM

@Mike the goat, @ Figureitout,

Don't worry about your "work history" -- It's who you know, not what you know. Sad, but very much true.

are you suggesting that someone else has been accessing your webmail box?
I wouldn't know anything about that ;) But he has about 16 unread emails.

WaelJuly 7, 2014 2:18 AM

@Mike the goat,

something which I will likely have to sign up for reluctantly given I have real concerns about privacy and these social network providers. But I do hope to land something half reasonable somewhere on the west coast - perhaps pen testing, security auditing, etc.
You have no privacy -- period! Send your resume around. The worst that can happen is you get no response. You'll have to change the name "Mike the goat", though -- It doesn't look too professional on a resume! I suggest you remove "Mike" from your name before you send your resume -- HR people have little sense of humor ;) Then again, I hear if you apply for a position on Linkedin, it ends up directly with the hiring manager.

Nick PJuly 7, 2014 11:36 AM

@ Mike the Goat

"The first one is that a lot of my online work has been done under a variety of aliases and that documenting them will essentially negate the very purpose of having a pseudonymous identity."

Not true. If you used PGP, then you can say you can prove those on demand. Then, you just sign a document with the key. If you didn't use PGP, you put together evidence that you're the account holder. Again, you show this on demand and they have to agree to a NDA about any detail not in the resume. You can also have an independent party, like a notary, look over all the details to certify that part of your resume so they can just call them and be told its legit. Many options all with a theme of selective, ephemeral disclosure of critical details.

"The second issue is that I worked for a few years on a black project which I am legally not even allowed to document, and that's a real shame as it was some groundbreaking work which I am very proud of. "

That's the problem with black projects and other work under strong confidentiality agreements. If I'm ever at DEFCON or Black Hat, I'm going to be challenged along the lines of "what have you done?" My reply can't include much detail. So, going from private to public credibility wouldn't be easy past the list I have of almost everything I've posted here.

Still might be hope for you. For one, if it's a classified govt project then it has an owner per classification system. Contact the organization or person with authority on that information. Ask them for permission to speak of certain details in certain ways. Have a few examples to run by them. If the data is no longer critical to national security, then include an argument to that effect especially referencing similar details publicly released for other projects. So long as you have a letter from the classification authority that those elements in your resume are non-classified, you should be good if a legal battle happens.

As for the specifics, here's a few examples I might have used (getting vaguer each time):

1. Modified the UDT protocol for a given application to improve performance.
2. Delivered a TCP replacement to improve performance in their systems.
3. Delivered a customized networking stack to improve performance over vanilla implementation.
4. Sped their network up.

1. Used a secure kernel and highly assured guard software to safely accept email from one isolated network to another.
2. Implemented a dedicated, high-security appliance to allow email (and only email) to come through the network.
3. Delivered a solution for securely receiving email on isolated networks.
4. Expanded communications capabilities and security on their critical networks.

Note: No 1 is still doesn't reveal specific information as there are many kernels, guards, etc commonly used in classified sites. It's even in guard's marketing material. Something like this is an argument for allowing you to mention it.

1. Designed a tagged processor architecture to prevent code injection.
2. Modified the processor to prevent code injection.
3. Modified system to prevent code injection with high assurance on all running software.

Note: In this case, the first clearly describes the mechanism, the second might represent dozens of mechanisms while giving the location of change, and the third just describes the result while giving no guesses on what was changed. My resume mostly does 3 with me explaining it in person. It's also why my resume looks like bullshit. Haha.

So, if classification authority will accept a proposal, you break down the points for this work as I have. You then create more and more watered down versions of each. You pick what you think is acceptable with a justification. You have them choose which variants of each that they're OK with. Then, you combine those and send it in for final approval. To be clear, I've never tried this for a black project as they've only copied my work that I'm aware of. (a**holes...) However, it might work as these kind of review and controlled release processes are how we get FOIA documents. And it's the classification owner that decides on each of those.

"and I've noticed that things like LinkedIn accounts are now pretty much mandatory - something which I will likely have to sign up for reluctantly given I have real concerns about privacy and these social network providers."

Yeah, those things can cause problems for semi-anonymous posters here. Just remember to set the privacy settings very carefully. ;)

re conferences, case histories, etc

All sounds good. You should also consider a role that combines hands-on and management. Makes your age/experience more worthwhile while increasing job security. Also, jobs with a physical proximity aspect reduce odds of offshoring.

FigureitoutJuly 8, 2014 12:54 AM

Mike the goat
--Since I've mentioned I've lived in Belgium, are you willing to say where you lived? There was an individual here in the US who I thought "was you" who did network security for a large drug company here (w/ global locations) and mentioned many times work in CA...For whatever reason he took an intro programming class even though there was clearly no point to do so...Cool guy, but just a little odd (the circumstances); wish I would've gotten to know him a little better...But I assume you're ready for the cost of living in CA.

RE: linkedin.com
--I finally caved and updated my dead account, and I hadn't participated in any social network (besides this blog quite a lot and a little on hackaday) and got rid of the smartphone. I lost track of so many of my friends, I really miss them...I could've made good use of my global network as they weren't poor, b/w diamond dealers and stock brokers w/ homes in the Carribean, I would've had a potential legit source of funds for a secure chip project, potentially. Some were really that rich. I made the sacrifice to make a political point of my anger against the loss of our privacy and digital data flying around everywhere like an insanity parade; stupid, I'll flood it w/ garbage.

RE: not being able to document your work
--It's a tragedy, I'm sorry. You're being censored from speaking about what you've done in your life to people, has that really hit you yet...? Sure commercial NDA's exist and are a dime a dozen and I'll respect ones when I respect the company and certain aspects of a technology, it's tricky but I can still say what I do and I'm not really afraid. It makes me glad to think that I made the right choice to completely avoid the evil that is the MIC and gov't contracting, no matter how big it is becoming. I can live in poverty quite fine if need be 'til I'm dead, so long as I don't contribute to that sheer evilness. Not caring about girls or having a vast social network helps (I've got my tight-knit group which I would die for).

RE: a blackhat presentation
--Like I said to Clive Robinson (who probably got all nervous or would have a hissy fit over how many hacks he's "already done better than you" lol), do it. Be interesting I'm sure.

RE: my email made up in 2 seconds and no care for
--It was meant as a joke, so no I give zero (0) f*cks about it and at least they spelled my real name right! :p

Regardless, hope you find a decent job in CA.


Wael
It's who you know, not what you know. Sad, but very much true.
--I cringe at that statement, b/c w/ 2 seconds of thought you can see that we'll all be idiots that know each other...I highly disagree w/ the statement and aim to change that stupid statement.

But he has about 16 unread emails.
--Aww, did you delete like 14 of them?! Oh you silly rabbit, tricks are for kids! Every connection can be traced back BTW! haha :p Are you going to join IEEE this year? I need you help to make it a successful year.

WaelJuly 8, 2014 3:50 AM

@Figureitout,

I highly disagree w/ the statement and aim to change that stupid statement...
Good luck. After you've been in the industry for a few years, let me know if you still uphold your conviction :)

SardokanJuly 20, 2014 9:29 AM

@Wael

I have ordered a blackphone mostly to stop commercial profiling and cut the line with apple and google

You should search prismicide on indigogo, it's possibly the security device you want to plug in ;)

Nick PJuly 20, 2014 11:56 AM

@ Sardokan

There are security guides and ROMs a Google away one can use to do same thing. They're cheaper than Blackphone, too.

Fush YumengAugust 25, 2014 6:59 PM

The website is located in Switzerland, not China. .ch is the national domain for Swiss websites, Chinese websites are set up on the .cn domain.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.