Security Vulnerabilities in the RCS Texting Protocol

Interesting research:

SRLabs founder Karsten Nohl, a researcher with a track record of exposing security flaws in telephony systems, argues that RCS is in many ways no better than SS7, the decades-old phone system carriers still used for calling and texting, which has long been known to be vulnerable to interception and spoofing attacks. While using end-to-end encrypted internet-based tools like iMessage and WhatsApp obviates many of those of SS7 issues, Nohl says that flawed implementations of RCS make it not much safer than the SMS system it hopes to replace.

Tags: cell phones, encryption, protocols, security engineering, SS7, vulnerabilities

Posted on December 16, 2019 at 6:00 AM • 8 Comments

Comments

Me • December 16, 2019 7:46 AM

Oh, I thought (from the conversations on the Green Site and the Red Site) that this was common knowledge.

Jeff Hall • December 16, 2019 2:39 PM

Flawed implementations are always an issue with any protocol. Why should RCS be any different?

Clive Robinson • December 16, 2019 3:42 PM

@ ALL,

Quite some time ago I listed on this blog what I thought would be the SigInt agencies priority list of things to attack,

1, Standards,
2, Protocols,
3, Implementations,
4, Known plaintext.

What triggered off my thinking was the retirment speach of Bob Morris senior, who was the NSA chief Scientist (and father of the Morris Worm author).

In it he dropped the hint that the target of the NSA was to get large quantities of “Known Plaintext” it was also at a time when Microsoft were “Front Loading” all their MS Office user files with around 4kByte of mainly unchanging data.

Thus I assumed that from the NSA point of view unless people were smart enough to use various tricks like “Russian Coupling” then they would have mainly achieved the “Known Plaintext” courtesy of Microsoft and friends.

But there was the AES competition that I and others think thr NSA put the fix in via NIST. Put simply “fast code” is going to be full of information hemorrhaging time and power based side channels and it’s a kind of “either or” problem. That is you can have either speed or security, take your choice. The NSA would have known or atleast taken the reasonable guess that as the “fast code” had to be published as part of the competition, software developers would just take the AES competition code and put it in their own software and library code. Which is what happened. The result was that although the algorithm might have been secure, the implementation in effect bypassed the security via the key and plaintext leaked via the side channels. So the NSA would have mainly achieved the “Implementation attack” courtesy of software developers who did not know any better.

Obviously there have been multiple instances in protocols and algorithms but the Dual EC DRNG and an aleged bribe to RSA is the one most will remember. I guess the NSA were none to happy about both asspects of this coming under the spotlight and their “finessing” becoming not just public but in effect reversed.

As for standards, if you have ever been involved with Telecoms standards you will be familiar with the “tag team tricks” of the Five Eye nations technical representatives and their equivalent of “think of the children” with their faux or at best improbable event senarios to put plain old “back doors” like “Operator listen in” into communications standards.

RCS just reeks of protocol and standards manipulation by the SigInt community through known intermediaries like “Google”. You won’t be easily able to prove it, but you can be reasonably sure that the Five Eyes SigInt agencies will all be there pushing as hard is as seemly behind the scenes.

So I’m far from surprised that the RCS standard is “wooly” as it encorages incompatability of implementation issues at the protocol level. With the result it opens the door wide to “fall back issues” that positively encorage Man in the Middle attacks…

Which I can see happening by the shovel full with RCS.

Before somebody says “conspiracy” just remember we’ve seen it over and over. Though atleast people are getting more suspicious it eas the atrocious behaviour of NSA representatives that got the spotlight drawn onto Dual EC DRNG that got it withdrawn by NIST.
Also remember the push back against Simon and Speck becoming standards[1] for similar reasoning.

[1] it was with ISO standards this time, and to be honest I can see why Simon and Speck got the rejections they did,

https://www.theregister.co.uk/2018/04/25/nsa_iot_encryption/

The point is that as stardards they would now be pointless for the original reasons stated of “IoT devices” basically $1 System On a Chip (SoC) devices are more than powerfull enough. About the only place left for them is RFIDs and even that is debatable. So best not to have anything to do with Simon and Speck.

SpaceLifeForm • December 16, 2019 4:02 PM

@ Clive

All ECC bad? Or just the known NIST curves that are known to be bad?

Sorry, sorta OT, but related, NIST wise.

Curious your thoughts on ECC.

SpaceLifeForm • December 16, 2019 4:11 PM

One thing to consider.

RCS moves the interception points to ip protocol, instead of just pure SS7.

Not that there do not exist interchange points between ip and SS7.

But, it may be slightly[0] more secure to use RCS over ip, and maybe telcos never see the comms.

[0] – for small definitions of ‘slightly’

Clive Robinson • December 17, 2019 12:41 AM

@ SpaceLifeForm,

All ECC bad?

I prefer to say “unproven” rather than “bad”. Because although it does not change the way I treat a technology it does not imply I have any “proof” one way or the other to found my “caution”[1] on.

I regard ECC as “new technology” that whilst it has some apparent upsides such as shorter keys[2]. That benifit does not confer other advantages such as enhanced security.

To assess ECC’s security in the current state of “open knowledge” is not an easy task even for those steeped in the required knowledge domains. But what we do know is that we have no ability to assess it’s security against hidden or “closed” knowledge or future knowledge.

If you look at DES for instance it was designed in part with “hidden knowledge” possesed by the NSA in their closed community. Eventually that hidden knowledge became open knowledge. But interestingly finding it spured on research that found another type of cryptoanalysis.

Likewise if you look at the history of the RSA algorithm whilst we talk of “the product of the PQ prime pair” over time it was found that not all primes were equal, thus prime pairs. This means that there are further constraints on which primes are and are not usable. I fully expect there to be future knowledge that further restricts which primes should be avoided. For instance solving the “Twin prime conjecture” will most probably require knew fundemental knowledge, such knowledge tends to have broader consequences. When this might happen is obvioisly unknown and very much dependent on who and how many look at it, such is the nature of research.

More recently if you look at the Dual EC DRBG the NSA apparently had hidden knowledge of and thus exploited it to their advantage. Eventually that hidden knowledge became open knowledge forcing NIST to drop the algorithm the NSA had probably backdoored.

The logical conclusion based on history is there is very probably more closed knowledge we have yet to find with regards ECC. Likewise we can expect future knowledge with regards ECC.

The only fly in the ointment, is that Quantum Computing (QC). This has already moved open community crypto research into other areas. Which might well mean that research in areas that effect ECC security might well diminish.

Personally I’m not to fussed about QC in the near term, and even in the long term it may well not deliver on it’s promises in an implementable let alone effective method. Remember QC research has been going on longer than ECC research.

Thus ECC might have a crypto future and research into it get to the point where it is sufficiently tested to be considered “proven”.

But that might not happen, as you also you have to think about what advantages RSA and ECC has given us and why carefully. We were quite happily using crypto prior to their discovery and we still are today, that is the bulk of crypto in use is still symmetric not asymmetric. Whilst there has been a phenomenal increase in crypto usage was this because of of the availability of asymmetric algorithms or for other reasons?

I happen to think it’s for other reasons, basically many technologies reached sufficient maturity to make high speed data communications a reality, and that was highly desirable in it’s own right without security (think HTTP -v- HTTPS history).

What asymmetric algorithms did do was to solve a “Key Distribution” problem quite computationaly inefficiently. We know that, the key distribution problem can be solved in other ways. Because asymmetric algorithms did not actually solve the “trust issue” we have many hierarchical Certificate Authorities (CAs) that have moved the trust issue one step away, nothing more.

The trust issue is actually not a crypto issue, it’s something that can be helped with crypto. That is the solution to crossing a canyon or river is a bridge, a bridge can be made of many things from rope through to carbon fiber. A high tensile bolt can help build a bridge structure but a bolt is not essential to or actually a requirment for bridge building.

From this we can realize that the “trust issue” can be solved without hierarchies and without crypto.

Asymmetric crypto algorithms are therefor an intetesting development in crypto history. But they might well turn out like many examples in nature, of something that gets replaced by something else, in effect getting out-evolved thus redundant.

[1] Likewise I prefere to say “caution” rather than “suspicion”.

[2] All a shorter key realy tells you is that it has less potential “entropy” than a larger key, which for various reasons is not very helpfull.

MarkH • December 17, 2019 11:41 AM

@Clive:

Disclosure: my knowledge of ECC is pretty much limited to “what I read in the newspapers” … I don’t pretend to understand its workings (it’s one of many items on my list of things I’d like to delve into).

That being said, my naive picture has been that the primary ECC applications base their security case on the difficulty of computing discrete logs in the setting of addition groups in suitably constructed elliptic curves — the elliptic curve discrete log problem (ECDLP).

When you write of your caution concerning ECC, are you thinking of the risk of a “break” in the solving ECLDP?

ECC is more than 30 years old now, so I imagine ECDLP to be what is called a “well-studied problem” — enough smart people have attacked it for long enough, that future progress is likely to be slow (of course, this is never guaranteed).

Perhaps, ECDLP has been studied as deeply as the discrete logarithm problem in prime-modulus multiplication groups when the original Diffie-Hellman exchange was proposed.

In essence what I’m asking, is where do you expect that weaknesses might show up?

SpaceLIfeForm • December 17, 2019 4:28 PM

@ Clive

Thanks. Overall, thinking same page.

‘From this we can realize that the “trust issue” can be solved without hierarchies and without crypto.’

Definitely want to avoid the hierarchy problem, no doubt.

But, I think the are two different meanings of ‘trust’ to consider.

One, is trust of who you are doing a comm with. Personal meet can address that angle. Or, chains of keysigning. Or, as mil does, pre-arranged codebooks, timed broadcast, and/or numbers stations.

The second issue of trust, is trusting that the comm itself is not manipulated in FLIGHT, or even at REST.

For that, there must be crypto.

Even if RF, the reciever must be able to detect a jam because the message was not properly decodable.

I guess a jam can be so bad that it is just noise, but if jam in place, I would prefer to trust the message received via crypto than just trust it.

[1] Likewise I prefere to say “caution” rather than “suspicion”.

I was thinking of safecurves, and those they found to have issues.

[2] All a shorter key realy tells you is that it has less potential “entropy” than a larger key, which for various reasons is not very helpfull.

I’m not convinced that a large RSA key definitely has more entropy than a shorter ECC key.

Potential is the keyword.

Schneier on Security

Security Vulnerabilities in the RCS Texting Protocol

Comments

Leave a comment Cancel reply