US comms watchdog calls for more scrutiny of submarine cables that land in 'adversary countries' One of the four commissioners of America's communications regulator has called for more scrutiny of submarine cables between the Land of the Free and "adversary countries". "We must take a closer look at cables with landing locations in adversary countries," said Federal Communications Commission (FCC) Commissioner Geoffrey …
Why would you be sending data unencrypted anyway? If your traffic is in the clear, that's not a problem checking transit routes will solve. Whadya mean your email provider cant even use STARTTLS? (firewall of china MITM notwithstanding)
Traffic analysis metadata (who talks to who and how often), can be obtained *lawfully* by any western government.
Why complain about other govs going it also?
Yes it is a mystery to me too why they wouldn't simply encrypt the entire data stream the cable is carrying. Maybe there isn't anything that can encrypt data at those rates or with acceptable latency, but if so that seems like a market opportunity for someone to sell a multi million dollar piece of specialized hardware to the operators of undersea cables.
You can break it up (i.e. every 1MB or whatever) and split it among multiple encryption devices if the data rate is too high. Latency I can't really imagine being a major concern, given the whole speed of light thing. Anyone Reg readers familiar with this stuff know why undersea cables aren't encrypted?
A carrier or in this case the undersea cable operator would not want to maintain encryption keys for other people's traffic that is transiting the link because then they're in a position to decrypt all that data given proper legal notice.
In all cases, the closer encryption happens to the endpoints, the harder it is for mass surveillance.
No I'm talking about encrypting the ENTIRE wire on one end, and decrypting it on the other. What is already encrypted would be doubly encrypted while it travels over the wire and have that extra layer of encryption removed and go back to its normal single encrypted state on the other end.
No need to manage keys or be responsible for someone else's security. It would simply prevent snooping by cutting the wire in the middle, since everything (even metadata like IP connection info that isn't encrypted by stuff like HTTPS) would be encrypted using the cable owner's key.
Worst case if someone got that key would be they could decrypt that traffic and snoop, which is identical to the situation today. But if I have a VPN connection to Europe carried over such a wire, removing that top level encryption wouldn't allow them to see the contents of my VPN connection - all they could get would be the source and destination IP address, packet sizes and stuff like that (which is valuable, but again no different than the situation today)
"No "
What part are you saying no to?
"No need to manage keys or be responsible for someone else's security"
That is literally what you are doing by encrypting the line.
Encrypting the entire wire is fine until you get a nice lawful letter saying "Decrypt it for us, or else. Oh by the way, you can't tell anyone you're doing it."
Like the person you are replying to says -
"A carrier or in this case the undersea cable operator would not want to maintain encryption keys for other people's traffic "
Its a cost to do it, a liability if its not effective, you can be legally coerced to undo it for powers that be, and you won't be allowed to tell your clients that you've been forced to undo it. Even if you were allowed, your business has just admitted the encryption is pointless.
Better to state its in the clear to begin with, and let your customers manage the their own risk.
You're kind of thick, aren't you?
You don't have much work "managing keys" if you encrypt on one end and decrypt on the other. And no need to worry about law enforcement requests, they aren't going to ask you to decrypt in the middle of the Pacific. You will have the data before/after it hits the encryption device on either end of the cable so they will NEVER ask you to decrypt what is on the cable. THIS IS EXACTLY THE SITUATION TODAY WITH A PROVIDER THAT DOESN'T ENCRYPT ITS SUBMARINE CABLE!!!!
The customers WILL be managing their own risk, because they can encrypt whatever the hell they feel like before they pass the data to the submarine cable provider. Why is that so hard for you to understand? Sheesh!
"You don't have much work "managing keys" if you encrypt on one end and decrypt on the other."
Encryption isn't just a magic wand you can wave over something. It has 2 parts. The algorithm and the key. The key itself can be a key pair in the case of asymmetric cryptography. Unless you have invented some other type of magical keyless cryptography...?
Will they keys/algorithms ever change as technology improves? How do you switch from one to the other without disruption?
"they aren't going to ask you to decrypt in the middle of the Pacific"
They don't need to. Read the article. Its about cable landing in China. They just have to tap the network company on the shoulder and say a condition of operation is giving them the ability to do a "lawful intercept" - which is whatever they say it is. That includes putting the data in the form they receive it (ie undoing any decryption the network folk have done)
Submarine cable interception is useful when you don't have access to one or more of the endpoints. eg For 5 eyes countries , intercepting links between any 2 non 5-eyes countries.
"The customers WILL be managing their own risk, because they can encrypt whatever the hell they feel like before they pass the data to the submarine cable provider. "
That's what I said. Why is that hard for you to understand?
"You're kind of thick, aren't you?"
It isn't *me* who thinks encryption is just a question of shouting "ITS ENCRYPTED", magical encryption person.
Don't get me wrong, I think the traffic *should* be encrypted (see my other comment about STARTTLS). That way even the "lawful interceptors" only see an encrypted stream. However, I don't see it as the cable operator's responsibility. That's why spy agencies don't like end-to-end encryption,.
Saying "just encrypt it" then showing a basic lack of understanding of what that entails while calling other people thick... Are you a manager?
They have warned that several high-profile projects in the works or recently completed have been backed or constructed by Chinese companies with connections to central government in Beijing.
They all do. And companies in US (or elsewhere) absolute have no connections to (or are definitely not influenced by) their relevant govenrment?
To do so, Starks laid out two recommendations for the FCC to take on. First, the commission should establish a centralized "national security inter-bureau task force" to review national security issues. The current watchdog system distributes issues to various bureaus, which "makes internal coordination challenging and risks inconsistent treatment of national security issues between different bureaus".
Oh, now I see. Need another pork barrel for mates.
This needs to be seen as yet another word used for misdirection of the reader. The basic flaw in the common use of the word is that there's an ASSUMPTION that encryption is only done once. Clearly wrong.
*
For example, anyone (like me) who simply does not trust the claims made for "end-to-end" encryption will use a privately defined encryption scheme BEFORE the message enters a public channel. And that's just the behaviour of a private citizen! In the commercial (or spook) world, who knows how many times data is encrypted BEFORE IT GETS TO A SUBMARINE CABLE.
*
For example, readers are offered the opportunity to find out what the message below might say.....is it a single encryption layer, multiple encryption layers....or just a cleverly assembled random list of (non-repeating) numbers?
*
0u$z0Rex0FnW149X1SyO1aRQ1Hw=0DB51Lqi1fCw
0VpE0GT00au$18rB1Tox1UuQ1DcV0imz1jTH0UgD
0eTB0vdV1XfA0CmA1VJy1ati08kn1PfR0YVG1WEv
04wC0S$e1bem0GWL0gtY1jUF1DXC0UOg0TN=0iJ=
05Ma1CAr0SD40VIx0Fem0POu0e1$1lNO1Uiz0l3X
1Yhz0Uaj09871JxJ1VUt1cQk1IJB1dVB0$ui1bxc
0qS2106u1J8c1eCH1dlY
*
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
