High-assurance Lawful Intercept 2017

High-assurance, Lawful Intercept: Revisited (2017 edition)

"what kind of system would allow for access with a warrant while also avoiding the "secure against nobody" state? Would the type of technical features that are implemented to comply with CALEA be such a system?"

I proposed [1] a high assurance lawful intercept system a while back, taking quite some flak for it. The fact is that the Constitution I fight for allows warranted search. Federal law expanded that to surveillance with CALEA. Assuming that's Constitutional or forced on us, then the government needs a way to get the specific data requested in the warrant. So, how can one design a system that let's them search it, maybe limits the search to what's in the warrant, and prevents their hijacking the system? What follows is a proposal that's simplified a bit in terms of details to make it accessible to a wider audience.

Well, I did come up with a straight-forward prototype. The base system is one whose code is open, the binary certified by government, and running on hardware that vets the correct system code is running. The core system, especially trusted computing base (TCB), is designed in a way to prevent the user from tampering with it. Risky actions run on top of the TCB constrained by its security policies. In such a system, the user data goes in different spots with different labels/tags than system data. That includes key material itself. Each app instance, system resource, log entry, etc is registered to a user. So, each users' stuff is identifiable, they're kept separate, they're private by default, and the system enforces this.

The intercept system is a component of the certified system. The intercept system can access keys, pull files, intercept networking, etc. However, it's limited to read access to prevent insertion of forged evidence. The LE administrator can pass a specific command to it for reading data or monitoring activity of a specific user. This is logged in a way the LE administrator can't erase. The functionality of commands may vary from a simple read to "Snowden's full data & metadata on anyone who emailed him" to a modifying an executable for live interceptions. These will require custom software to be written that might be a threat. So, there must be a way to write these plugins without (a) them doing things they shouldn't or (b) compromising the system.

The best way is an interpreter + safe language. The language will be memory-safe with runtime checks added by the compiler. The interpreter will be stronlyg-verified with no unsafe libraries or JIT (i.e. risky stuff). The more English like the language is, the better. Wirth's languages or declarative stuff like SQL come to mind. The routines would be reusable, designed for a certain type of collection, inspected by third parties the government doesn't control, and vetted from source to binary similar to main software. They'd only interface with the system through message passing to the constrained lawful-intercept component. The commands would produce (or analyze) the data to produce intelligence to be delivered to government. System would certify the integrity and authenticity of that data before passing it on.

The resulting system is a nice compromise. The system lets its owner do their work. The system provides its users as much security as its designers want to put in. The lawful-intercept core can be designed with just as much security to ensure only human-understandable, pre-vetted commands that do *only* what they say they will do. Each detail I've mentioned has been in published academic work or commercial products in high-assurance, security sector. Most of it by MLS systems from the mid-1980's to early 1990's. Putting them together would take minimal to substantial resources depending on the level of assurance needed. I say nothing less than high-assurance using existing components. Standard requirement is 2 years plus a few million. I say add a few million and three years more for diverse reviewers each with long resume of breaks on code, protocols, kernel designs, etc. The first system, SCOMP, took five years of review and pentesting to be certified. I think one that puts the whole nation at risk, if it exists at all, should get *at least* that amount of effort.

So, high assurance lawful intercept is possible. It provides strong assurances to all parties involved. In this scenario, the government has already forced it by law. Their often dirty tactics make me want some assurances they don't abuse their power. Hence, this design that can be built with existing security engineering technology rated at strong standards (EAL6-7). Like remote administration, the model still provides strong security against everyone who is not given access. It's worth designing and vetting at least in case such a law passes. I'd rather not be unsafe for the 3-5 years it takes to get an secure, LE system done.

(Originally posted 2014 on Schneier's blog. Revised mainly to clear up my position and presentation on it.)

Nick P.
Security Researcher/Engineer
(High-assurance focus)