Richard Bejtlich's blog on digital security, strategic thought, and military history.

Thursday, May 31, 2007

I Have Seen the Future, and It Is Monitored

Today I spoke at the ISS World Spring 2007 conference in Alexandria, VA. ISS stands for Intelligence Support Systems. The speakers, attendees, and vendors are part of or support legal and government agencies that perform Lawful Intercept (LI) and associated monitoring activities. Many attendees appeared to be from county, state, and federal law enforcement agencies (LEAs). Others were wired and wireless service providers who are responsible for fulfilling LI requests.

This was a very different crowd. Even when cops attend security conferences (like Fed, I mean Black, Hat) the vibe is different. At security cons it's seen to be cool if one has mad offensive sk1llz. This group was all about acquiring the information needed to go to court to convict bad guys.

One theme immediately grabbed my attention, and it's going to eventually affect every entity that provides technological services:

Today (and previously), if I wanted to perform surveillance against a target, I would tap his phone line. In the very old days I would physically attach to phone lines, but these days I work with the telephone company to obtain electronic access. The telcom is a service provider and as such is subject to CALEA, which mandates providing various snooping capabilities for LEA use.

Also today, and definitely tommorow, targets are using VoIP. VoIP can be monitored by watching broadband lines, but "tapping a line" is not sufficient. The classic deficiency is call forwarding. As described at the conference today, assume a LEA is watching all broadband traffic to and from a target. If the target enables call forwarding through his VoIP provider, a LEA watching network traffic will not see a call come in if the VoIP provider forwards it elsewhere.

Therefore, gaining access to that critical information requires monitoring the service, not the line.

Extend the services to be monitored beyond VoIP. Suddenly you can probably imagine many scenarios where LEAs would want to essentially be inside the service, or able to tap data directly from the service. The line to the target is secondary. For example, why try to follow a target from Internet cafe to Internet cafe if you can just watch his chat room, Web forum, or other meeting place directly?

This seems less like Big Brother and more like Embedded Brother. Any application wich law enforcement might consider a source of data on a target could be compelled by law to provide a means for LEA to perform lawful intercept. Already we are seeing signs of this through various data retention directives. One of the conference panelists mentioned a story from Germany that makes this point. He said Germany (or at least part of it) has a system that tracks cars paying tolls. When the system was deployed it was forbidden to use such data for tracking car owners, even if crimes were committed. However, a person was run down at a toll booth. After the crime happened, an outcry erupted to use the toll logs to identify the culprit. This is the sort of "emergency thinking" that results in powers be granted to LEAs to become ever deeper into technology services.

One financial note: consider buying stock in log management and storage vendors. All of this data needs to be managed and stored.

In one of my classes I list the reasons why people monitor, in this progression:

Performance: is our service working well?

Fault: why does our service fail?

Security: is our service compromised?

Compliance: is our service meeting legal and regulatory mandates?

Many companies are still at step 2. Step 3 might be leapfrogged and step 4 might be here sooner than you think. Hopefully data collected for step 4 will inform step 3, thereby serving a non-LEA purpose as well.

Incidentally I did not hear the term encryption mentioned as a challenge for law enforcement. I'll let the conspiracy theorists chew on that one. In a service-oriented lawful intercept world, I would imagine LEAs could access data unencrypted at the service provider if end-to-end encryption were not part of the service. In other words, maybe your VoIP call is encrypted from you to the provider, and from the provider to the recipient, but the LEA can intercept at the hub of the communication.

Update: I want people to understand that me predicting this development does not mean I agree with it. I prefer privacy to what's going to happen.

5 comments:

As the LI framework becomes more formalized, I predict that the usage of end-to-end encryption will increase significantly.

Today we can brute 56 or 64 bit keys using machines like Copacobana , and the US government is said to have even more powerful brute forcers. These machines still need anywhere from a few hours to a week to perform an exhaustive search of the key space. Move to longer key lengths (128-bit or 256-bit) and the game is over for LEA.

I think that LI requirements need to be built into the network protocols such as SIP/TLS/SSH/etc. Without the co-operation of these protocols, I cant see how end-to-end encryption can be handled at all.

Some random thoughts about incorporating elements of LEA in existing protocols.

1. Prevent a principal from negotiating a cipher greater than 'x' bits. This will allow bruting by agencies with access to the necessary hardware.

2. Requirements for LEA peering with entities that implement these protocols. These peers would simply tap into the required keying material.

"I think that LI requirements need to be built into the network protocols such as SIP/TLS/SSH/etc. Without the co-operation of these protocols, I cant see how end-to-end encryption can be handled at all."

Not going to happen. You might get LI with the complicity of the endpoints... but seriously, would you use a broken crypto protocol when a perfectly (so to speak) good one is available?

Other measures, legal etc. discussed elsewhere, might deal with the end-to-end issue in less direct ways but widely deployed protocols will not change. You can ask Theo about incorporating LEA provisions into OpenSSH, and while he has mellowed in recent years, I can guess what his answer will be.

I think that, generally, people who design/implement crypto have a strong cipherpunk streak, good luck overcoming that.