How To Compete With NSA By Hacking a Verizon Network Extender 56
New submitter Anita Hunt (lissnup) writes "This snooping hack-in-a-backpack could become a hot Summer accessory, since Reuters reported that 'researchers at iSec hacked into a Verizon network extender, which anyone can buy online, and turned it into a cell phone tower (video interview) small enough to fit inside a backpack capable of capturing and intercepting all calls, text messages and data sent by mobile devices within range.'"
Re:Encryption? What Encryption? (Score:5, Interesting)
Why would you need to sync your phone to the station to get it to work, let's just send unencrypted communication all over the place.
We should be careful in just encouraging encrypted communication, because the usual interpretations of this provide no security at all, and were rejected back in the ARPAnet days of the 1960s by the security advisers.
The usual interpretation of "encrypted communication", of course, is the frequent suggestion that "the Internet" itself should do encryption. This is especially suggested by people who've figured out that the average user doesn't stand much of a chance of doing it right, with modern comm software.
But having "the Internet" do the encryption actually means that the encryption is done by your comm supplier, i.e. your ISP or phone company. What this means is that your comm supplier is the one who also does the decryption, so they have complete access to everything. The recent stories about the close ties between government security agencies and the comm companies show that this would be no security at all.
What was decided back in the 1960s, and what anyone with a basic understanding of security will agree with, is that the low-level comm stuff shouldn't be burdened with any security measures. They are simply a waste of cpu time, since they make your messages accessible to the people who run the low-level comm stuff. The low-level stuff should therefore be tasked simply with getting the bits across as fast as possible. To qualify as secure, any encryption must be handled by the two end-points in a conversation.
Note that this doesn't mean that the (human) end users need to be the ones doing the encryption. What it means is that the encryption software must be running on the piece of hardware that they're using, not by anything further away in the connection.
Of course, then you have the next problem, of preventing spy software from being installed on the hardware at either end. But that's a different issue.
The primary understanding is that we should insist that "encrypted communication" be done only end-to-end. Anything else inherently makes your info available to whoever owns the hardware that's running the encryption software. (And it makes the whole comm system run slower, since encryption software does use cpu time, and if it's not in the end systems, it's 100% a waste of that cpu time.)
The major use-level issue is whether we can create encryption software that runs in the users' gadgets, and which the users can actually use correctly, and which won't be compromised by builtin backdoors such as keyloggers that were installed by the comm companies.
Re:Encryption? What Encryption? (Score:2, Interesting)
Not necessarily. You could just have the initial key exchange built into the initial handshake, e.g. like this:
The SYN packet contains the public key certificate of the client.
The SYN/ACK packet contains the public key certificate of the server, and a hash of the client's certificate signed with the server's private key.
The final ACK packet contains a hash of the certificate the server sent, signed with the client's private key.
At this point, the communicating computers know enough about each other to safely encrypt their data stream without any middle man (including the ISP) being able to read the messages. Also, they know that each other computer has the private key for the public key certificate they've sent. All further data then can be encrypted, only the source/destination IP and port need to be unencrypted (because those are needed to route the packets). Since the encryption would already happen at the protocol level, the only thing which would ever go over the lines unencryted would be IP addresses, port numbers and public key certificates.
Of course at this point you did not establish the identity of the server and/or the client, so to prevent MITM attacks you'd need further means to authenticate the server. But the very basic operation of point-to-point encryption of all traffic of a connection can very well be done at the protocol level.
Re:Power to the people (Score:5, Interesting)
Not a subversion at all. Perhaps you're forgetting that congresspeople are ordinary people, as are judges.
"You wouldn't want us to leak to the press that affair you've been having, would you, Senator? Then I trust you'll do better at ensuring the NSA is not spying on your own citizens."
"You wouldn't want us to leak to the press that you took a bribe from the Monsanto corporation, would you? Then I trust you'll rule that we have standing to sue the federal government over the PRISM program."
And so on. Not saying that two wrongs make a right, but enough rights do make a left.
Re:Power to the people (Score:4, Interesting)
You'd be surprised. I once caught someone embezzling from the company we worked over discussing it via IM with their accomplice, full confession via IM, ON THEIR WORK COMPUTER. Pawned.
After a few years in corporate security it would not shock me in the slightest. People get sloppy.
Even professionals. See the Opsec talk summary here: https://www.blackhat.com/us-13/briefings.html#Cole [blackhat.com]
Min