Print 34 comment(s) - last by NellyFromMA.. on Jul 31 at 11:51 AM

The question of whether it's legal for them to ask for these SSL keys or not is unclear

The feds are trying to creep further into the personal lives of Web users by requesting master encryption keys from Internet companies. 

According to a new report from CNET, the Federal Bureau of Investigation (FBI) and the National Security Agency (NSA) have both tried to obtain master encryption keys as part of their digital surveillance efforts, but there's a huge question as to whether they have the legal authority to do so. 

 Master encryption keys are crucial to Web encryption. They put contents of Web communications into code that is tough to crack using Secure Sockets Layer (SSL). If government agencies were to get their hands on these SSL keys, they could decode the content and peek into the lives of Internet users.

The NSA is also looking to get these SSL keys because it would allow for surveillance through its fiber taps, which are now heavily guarded by SSL.

SSL was originally put in place because of insecure and open Wi-Fi networks. Google adopted HTTPS (which appears in the browser to show that SSL is enabled -- back in 2010 for Gmail, and Microsoft did the same for Hotmail. Later in 2012, Facebook followed suit for its popular social network.

Now, these large Internet companies face the fear of government agencies trying to obtain the SSL keys and expose information on their users. Microsoft, Google and Facebook all said that they haven't given any SSL keys to the government, and agreed that they would fight against doing so. 

Other larger companies like Apple, Verizon, AT&T, Yahoo, Comcast and AOL haven't said if they've been asked for or have given SSL keys to the feds. 

But the larger companies fear that smaller Web establishments without deep pockets or a hefty legal department will give in to the government's requests for keys. 

SSL has certainly hindered the government's spying abilities, which is why they're coming directly to the source for the keys. But if all else fails, the feds have other avenues of getting what they need. For instance, companies like Packet Forensics help government agencies import "legitimate" copies of SSL keys -- which could possibly be obtained through a court order -- for spying on users. 

Speaking of a court order, it's not clear whether federal surveillance laws allow the government to ask for SSL keys -- even with subpoenas. Subpoenas call for gathering evidence related to an investigation, where SSL keys would seem to open up a treasure trove of data that may contain pieces of information relevant to an investigation, but likely most that are not.

Source: CNET

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: Too little too late
By Shadowself on 7/26/2013 11:46:40 AM , Rating: 1
Are you seriously suggesting that every "https" type transmission between you and the provider be done with each and every individual's key pair? Do you have any idea the level of overhead that would require? Do you really expect Amazon to keep (and update every year or two) every customer's public key and use that -- and only that -- for each of the 10s (or more likely 100s) of thousands of concurrent sessions they have at any given moment?

It's a nice idea in theory, but the practical implementation could be a business killer.

Plus, this would work great for transmissions that Amazon (or other provider) sends to you as you and only you (in theory) would be able to decrypt the traffic sent to you. But what about what is sent to Amazon by you and encrypted with your private key? Anyone (even the U.S. Government who could get your public key by any number of means) could decrypt traffic that you send out. You realize that secure two way communications requires two key pairs, not one? All traffic is generated with the public key by the sender and is decrypted by the private key of the receiver. When the traffic goes the other way a different key pair is used.

Are you suggesting each provider (e.g., Amazon) create a unique key pair for each of its customers giving the customer the "public key" and the provider holding the unique private key for each customer so that traffic from the end user has to be decrypted with the "private" key assigned to that individual but kept solely by the provider? And what's to keep the provider from giving that "private" key to the U.S. Government just as easily as the generic keys they are using now?

I truly don't see how this would be a practical solution.

RE: Too little too late
By EricMartello on 7/26/2013 8:16:42 PM , Rating: 2
Are you seriously suggesting that every "https" type transmission between you and the provider be done with each and every individual's key pair? Do you have any idea the level of overhead that would require?

LOL it already is done that way, except that the "trust" is given to the server rather than the client. The server keeps a private key for itself and sends clients its public key.

If this process were reversed, then establishing an SSL connection would have the client send its public key to the server and the server would use that key to encrypt the data.

This would effectively phase out the necessity of having "Certificate Authorities" because users would generate their own self-signed key pairs and maintain their own private key.

The per-session increase in "overhead" would be limited to the the inclusion of the client's public key to the session data...which may have been an issue when memory and storage space was limited, but is much less of an issue today. If your server is so limited, then you could request the public key from the client with each transaction so that you wouldn't need to store it locally on the server.

"This is from the It's a science website." -- Rush Limbaugh

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki