IP Traffic Monitoring
Your privacy online is a thing of the past. I’ve come up with a theory that could potentially already be in use by government agencies. It could be used today considering the government can now officially get away with it.
Building the Database
Contact graphs can be constructed by analyzing lightweight IP traffic logs at the ISP level. The only thing that needs to be logged is a tuple of (date, time, source_ip, source_port, target_ip, target_port, protocol, connect|disconnect). It would also be beneficial to log queries to DNS servers to reverse-map target IPs to their most probable DNS hostname (based on how long it takes between the initial DNS query and IP connection.) For higher level protocols, a filter can be applied for in-place traffic analysis for further breakdown. This would be useful for SOCKS proxies.
Forensic Analysis
Data can be fully collected only on endpoints that are marked as “suspect” or have links to a “target of interest”, ensuring that space is conserved on the endpoints that don’t really matter. Data for everyone else isn’t collected, ensuring irrelevant traffic is filtered out, and keeping audit log sizes filtered down to useful information. When a sufficient amount of data is collected, a full contact relationship graph can be built and analyzed for a more thorough forensic investigation.
Choosing Targets
What makes an endpoint “suspect”? They can be identified via the blacklist method, wherein known “bad” sites are flagged and all traffic to/from them is analyzed. A way to supplement this blacklist is using a whitelist, where a database of all known sites is built up over time, and any new sites that aren’t in the database are automatically flagged for analysis. For ISP users, I could take this a step further and say that if the goverment gets access to ISPs, we can switch the term “endpoint” with “user”, meaning a dynamic IP can’t hide them.
Encrypted Proxies
Encrypted tunneled traffic (such as SSH and SSL) can be defeated. When the data stream is captured on relevant targets, the key can be cracked when the logged data is automatically sent to a processing queue on a cryptanalysis server farm or supercomputer. Once the key has been found, the current and past data streams can be revealed and tunneling links can be extracted, making the contact graph complete.
Even if proxy traffic can’t be decrypted in a reasonable amount of time, an estimate can be put in place until a more definite answer comes back from the cryptanalysis server. We can safely assume that for every connection that comes into the proxy, there will be an (almost instantaneous) outgoing connection request. There may be overlap from non-proxy traffic that occur at the same time as the requested connection, so until more definite results get back, both the proxy server and the requesting connection are “tainted” and marked as suspect if the target site they connect to is also marked as suspect. An advantage to this system is that proxies (encrypted or not) are essentially rendered useless for masking someone’s trail.
Efficient Cryptanalysis
Cryptanalysis can be efficiently done. The government knows of, has standardized, and promotes existing algorithms that have fixed key sizes in their specs. AES (or Rijndael, which is an improvement on Serpent) usually has a fixed key size of 256 bits in most protocols. If enough hardware is thrown at it, the key can be cracked because the specs are already known. The only thing protecting your data is the computational complexity of the algorithm, which really just slows down brute-force cryptanalysis attacks on it on most consumer hardware. The government has more money and technology to throw at this equipment than your average Joe does. The cryptanalysis can also be sped up by reducing that computational complexity, such as with the proposed Extended Sparse Linearization attack. If there were a better attack against AES, you could bet that the NSA would want to keep that secret, considering the government uses it to keep a subset of its own information safe.
Known Passwords
Supposing it takes awhile to brute force passwords for users, it would be quite convenient to keep a database on all their known passwords. This database can be built up either by passively sniffing traffic for passwords and saving past decrypted passwords. These passwords (and combinations+permutations of them) will be used first in brute force attacks, greatly increasing a chance of a hit.
Crossing the Borders
Information can be effectively gathered even for those out-of-country ISPs who will not release their traffic logs by virtue of traffic monitoring on routers one hop before the information travels into or out of the US. We should only be concerned with traffic that crosses our borders, so analysis can be done there and risk analysis can be done so that we can tell which countries are abusing their use of the internet within our borders and appropriate action can be taken.
Conclusion
Even with an elaborate setup such as this, one can argue that if they have nothing to hide, then privacy shouldn’t be a concern. Even if you don’t have anything to hide, would you still feel a bit nervous if a stranger was standing outside your house listening in on your conversations? After all, as long as the conversations don’t have anything you wouldn’t mind someone else hearing, what harm could be done? We know he’d never misuse or abuse that information he collects either… Right?
Update
9/3/2008 – It seems Great Britain is already doing something similar to this.