Schneier on Security

Nick P • July 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.

Nick P • July 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.

Nick P • July 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.

Nick P • July 2, 2014 1:56 PM

@ Virmaline

You’re very welcome.

Nick P • July 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)

Nick P • July 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.
5. Used a secure kernel and highly assured guard software to safely accept email from one isolated network to another.
6. Implemented a dedicated, high-security appliance to allow email (and only email) to come through the network.
7. Delivered a solution for securely receiving email on isolated networks.
8. 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.

Nick P • July 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.