Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #154109 > unrolled thread

Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner

Back to article view | Back to comp.mobile.android

Contents

  Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E.R." <robin_listas@es.invalid> - 2026-06-10 11:44 +0200
    Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Jörg Lorenz <hugybear@gmx.net> - 2026-06-10 17:59 +0200
    Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-10 14:29 -0500
      Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E.R." <robin_listas@es.invalid> - 2026-06-10 23:19 +0200
      Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Theo <theom+news@chiark.greenend.org.uk> - 2026-06-11 22:32 +0100
        Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-11 20:18 -0500
          Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E.R." <robin_listas@es.invalid> - 2026-06-12 12:16 +0200
            Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-12 15:13 -0500
              Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Andy Burns <usenet@andyburns.uk> - 2026-06-13 08:29 +0100
                Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-13 15:52 -0500
                  Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Jörg Lorenz <hugybear@gmx.net> - 2026-06-14 07:35 +0200
        Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Jörg Lorenz <hugybear@gmx.net> - 2026-06-12 07:19 +0200
        Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E.R." <robin_listas@es.invalid> - 2026-06-12 12:19 +0200
          Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-12 15:59 -0500
        Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Theo <theom+news@chiark.greenend.org.uk> - 2026-06-12 23:11 +0100
          Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E. R." <robin_listas@es.invalid> - 2026-06-14 15:05 +0200
            Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-14 20:18 -0500
              Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E. R." <robin_listas@es.invalid> - 2026-06-15 09:24 +0200
                Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner VanguardLH <V@nguard.LH> - 2026-06-15 08:14 -0500
                  Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Theo <theom+news@chiark.greenend.org.uk> - 2026-06-15 16:29 +0100
                    Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner "Carlos E. R." <robin_listas@es.invalid> - 2026-06-15 21:21 +0200

Page 1 of 2  [1] 2  Next page →

#154109 — Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner

This is an article in Spanish, translated. I do not know if it applies 
worldwide.


<https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>

Android will detect calls with spoofed numbers by sending a real-time 
RCS message to the legitimate owner

By Joshua Llorach
Published 3 June 2026 10:50

Until last summer, it was very easy for malicious actors to spoof the 
number that appears on a mobile phone screen as the caller ID when a 
call rings. The lack of a system to validate numbers and their origin 
allowed spammers and other malicious actors to inject traffic into the 
network with a spoofed caller ID, a practice known as CLI spoofing.

Since June 2025, mobile operators have been filtering calls originating 
from abroad that use Spanish numbers without permission, as well as 
applying other validation checks to make this practice more difficult. 
Added to these measures is the system from Orange and Telefónica that 
displays a warning on the screen for suspicious calls.

Falsifying a number known to the victim makes the attack much more 
effective, especially in the age of AI, where it is very easy to imitate 
a person’s voice, so Google is joining this fight with its own measures 
against CLI spoofing.


The Android Phone app has started to verify the caller ID of incoming 
calls by connecting in real time to the supposed originating mobile 
phone to check that it is indeed the one making the call.

For this to work, both parties must be Android users with the Phone app. 
When the call rings on the recipient’s device, the phone sends an 
encrypted RCS message to the legitimate owner of the number to ask if 
they are actually making the call at that moment. In this way, the 
recipient’s phone can tell when the call is fake.

The idea is interesting, as it does not use OTT data traffic, but rather 
core network services, making the exchange of information faster and 
more reliable.

This feature is being rolled out first on Pixel devices running Android 
12 and above, but Google has released it as an open standard so that 
other phone apps and operating systems can use it, meaning that in the 
future it would be possible to verify numbers between Android and iOS if 
the parties involved wish to do so.

Translated with DeepL.com (free version)

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [next] | [standalone]

#154114

On 10.06.26 11:44, Carlos E.R. wrote:
> 
> This is an article in Spanish, translated. I do not know if it applies 
> worldwide.
> 
> 
> <https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>
> 
> Android will detect calls with spoofed numbers by sending a real-time 
> RCS message to the legitimate owner
> 
> By Joshua Llorach
> Published 3 June 2026 10:50

Very old news. And it shows how helpless Google is.



-- 
"Roma locuta, causa finita" (Augustinus)

[toc] | [prev] | [next] | [standalone]

#154118

"Carlos E.R." <robin_listas@es.invalid> wrote:

> This is an article in Spanish, translated. I do not know if it applies 
> worldwide.
> 
> <https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>
> 
> Android will detect calls with spoofed numbers by sending a real-time 
> RCS message to the legitimate owner
> 
> By Joshua Llorach
> Published 3 June 2026 10:50
> 
> Until last summer, it was very easy for malicious actors to spoof the 
> number that appears on a mobile phone screen as the caller ID when a 
> call rings. The lack of a system to validate numbers and their origin 
> allowed spammers and other malicious actors to inject traffic into the 
> network with a spoofed caller ID, a practice known as CLI spoofing.
> 
> Since June 2025, mobile operators have been filtering calls originating 
> from abroad that use Spanish numbers without permission, as well as 
> applying other validation checks to make this practice more difficult. 
> Added to these measures is the system from Orange and Telefónica that 
> displays a warning on the screen for suspicious calls.
> 
> Falsifying a number known to the victim makes the attack much more 
> effective, especially in the age of AI, where it is very easy to imitate 
> a person’s voice, so Google is joining this fight with its own measures 
> against CLI spoofing.
> 
> The Android Phone app has started to verify the caller ID of incoming 
> calls by connecting in real time to the supposed originating mobile 
> phone to check that it is indeed the one making the call.
> 
> For this to work, both parties must be Android users with the Phone app. 
> When the call rings on the recipient’s device, the phone sends an 
> encrypted RCS message to the legitimate owner of the number to ask if 
> they are actually making the call at that moment. In this way, the 
> recipient’s phone can tell when the call is fake.
> 
> The idea is interesting, as it does not use OTT data traffic, but rather 
> core network services, making the exchange of information faster and 
> more reliable.
> 
> This feature is being rolled out first on Pixel devices running Android 
> 12 and above, but Google has released it as an open standard so that 
> other phone apps and operating systems can use it, meaning that in the 
> future it would be possible to verify numbers between Android and iOS if 
> the parties involved wish to do so.
> 
> Translated with DeepL.com (free version)

So the non-spoofed caller makes their call, and then has to respond to a
text message?  Oh joy, 2FA comes to voice calls, too.

"When the call rings on the recipient’s device, the phone sends an 
encrypted RCS message to the legitimate owner of the number to ask if 
they are actually making the call at that moment."

One, only works when caller and callee are both Android users, and both
use a phone app with the integrated verification check.  Two, to
eliminate 2FA interference, the caller's phone app must automatically
respond to the RCS request by the callee's phone app, and the callee's
phone app must automatically handle the RCS response.

Texting is not a guaranteed communication venue.  What happens when a
call is received, but texting fails in either direction between caller
and callee?  And how does this scheme eliminate the delay in getting the
specially encoded text?  Texting is not always immediate.  Who is going
to wait 2 minutes for the texting to complete in both directions when
there is an incoming call?  After how many rings should the callee wait
before picking up the call?  Will the callee's phone app silence all
ringing until its validation text gets received by the caller, and the
caller's phone app sends back the response text, to when the callee's
phone app finally gets that response text?

I'm sure there are some glitches that will have to get ironed out.
Since texts are an insecure communication venue (no encryption), there
wouldn't be some means to spoof the response text the spammer sends to
the callee?  There are entire companies dedicated to providing spoofing
services, so I'm sure they'll figure out a workaround.

[toc] | [prev] | [next] | [standalone]

#154120

On 2026-06-10 21:29, VanguardLH wrote:
> "Carlos E.R." <robin_listas@es.invalid> wrote:
> 
>> This is an article in Spanish, translated. I do not know if it applies
>> worldwide.
>>
>> <https://bandaancha.eu/articulos/android-detectara-llamadas-numero-falso-11792>
>>
>> Android will detect calls with spoofed numbers by sending a real-time
>> RCS message to the legitimate owner
>>
>> By Joshua Llorach
>> Published 3 June 2026 10:50
>>
>> Until last summer, it was very easy for malicious actors to spoof the
>> number that appears on a mobile phone screen as the caller ID when a
>> call rings. The lack of a system to validate numbers and their origin
>> allowed spammers and other malicious actors to inject traffic into the
>> network with a spoofed caller ID, a practice known as CLI spoofing.
>>
>> Since June 2025, mobile operators have been filtering calls originating
>> from abroad that use Spanish numbers without permission, as well as
>> applying other validation checks to make this practice more difficult.
>> Added to these measures is the system from Orange and Telefónica that
>> displays a warning on the screen for suspicious calls.
>>
>> Falsifying a number known to the victim makes the attack much more
>> effective, especially in the age of AI, where it is very easy to imitate
>> a person’s voice, so Google is joining this fight with its own measures
>> against CLI spoofing.
>>
>> The Android Phone app has started to verify the caller ID of incoming
>> calls by connecting in real time to the supposed originating mobile
>> phone to check that it is indeed the one making the call.
>>
>> For this to work, both parties must be Android users with the Phone app.
>> When the call rings on the recipient’s device, the phone sends an
>> encrypted RCS message to the legitimate owner of the number to ask if
>> they are actually making the call at that moment. In this way, the
>> recipient’s phone can tell when the call is fake.
>>
>> The idea is interesting, as it does not use OTT data traffic, but rather
>> core network services, making the exchange of information faster and
>> more reliable.
>>
>> This feature is being rolled out first on Pixel devices running Android
>> 12 and above, but Google has released it as an open standard so that
>> other phone apps and operating systems can use it, meaning that in the
>> future it would be possible to verify numbers between Android and iOS if
>> the parties involved wish to do so.
>>
>> Translated with DeepL.com (free version)
> 
> So the non-spoofed caller makes their call, and then has to respond to a
> text message?  Oh joy, 2FA comes to voice calls, too.

Yes, I wonder.

> 
> "When the call rings on the recipient’s device, the phone sends an
> encrypted RCS message to the legitimate owner of the number to ask if
> they are actually making the call at that moment."
> 
> One, only works when caller and callee are both Android users, and both
> use a phone app with the integrated verification check. 

The Google telephone app, which is the default.

> Two, to
> eliminate 2FA interference, the caller's phone app must automatically
> respond to the RCS request by the callee's phone app, and the callee's
> phone app must automatically handle the RCS response.
> 
> Texting is not a guaranteed communication venue.  What happens when a
> call is received, but texting fails in either direction between caller
> and callee?  And how does this scheme eliminate the delay in getting the
> specially encoded text?  Texting is not always immediate.  Who is going
> to wait 2 minutes for the texting to complete in both directions when
> there is an incoming call?  After how many rings should the callee wait
> before picking up the call?  Will the callee's phone app silence all
> ringing until its validation text gets received by the caller, and the
> caller's phone app sends back the response text, to when the callee's
> phone app finally gets that response text?
> 
> I'm sure there are some glitches that will have to get ironed out.
> Since texts are an insecure communication venue (no encryption), 

It is RCS, there is encryption.

> there
> wouldn't be some means to spoof the response text the spammer sends to
> the callee?  There are entire companies dedicated to providing spoofing
> services, so I'm sure they'll figure out a workaround.


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154132

VanguardLH <V@nguard.lh> wrote:
> "Carlos E.R." <robin_listas@es.invalid> wrote:
> > Translated with DeepL.com (free version)
> 
> So the non-spoofed caller makes their call, and then has to respond to a
> text message?  Oh joy, 2FA comes to voice calls, too.

I was assuming that it's making an automatic handshake with the calling
phone via RCS, not asking the caller to do it.

ie:
1. Recipient phone app receives a call from +34567890123

2. Recipient phone app sends an RCS to +34567890123 saying 'hello RCS client,
I'm +34xxxxxxxxx, are you calling me?'

3. Sending phone RCS app sends an RCS back saying 'yes, I'm currently calling
you now' or 'no, I'm not calling you right now'

4.  If recipient gets the 'yes' RCS they display a green tick, if they get a
'no' they display a 'suspicious incoming call' message and maybe block it. 
If they don't get an answer they don't display anything.

That could be done automatically without the sender having to do anything.

If someone is spoofing numbers they aren't receiving messages on them, so
the RCS will go to the genuine number owner, rather than the one doing the
spoofing.

The trouble is that calls from iPhones or from businesses won't operate
this system, so it doesn't actually help very much.  And even if iPhones do
adopt it, it seems unlikely that businesses will, since business telecoms is
mostly SIP based and has nothing to do with RCS.

Theo

[toc] | [prev] | [next] | [standalone]

#154133

Theo <theom+news@chiark.greenend.org.uk> wrote:

> VanguardLH <V@nguard.lh> wrote:
>> "Carlos E.R." <robin_listas@es.invalid> wrote:
>>> Translated with DeepL.com (free version)
>> 
>> So the non-spoofed caller makes their call, and then has to respond to a
>> text message?  Oh joy, 2FA comes to voice calls, too.
> 
> I was assuming that it's making an automatic handshake with the calling
> phone via RCS, not asking the caller to do it.
> 
> ie:
> 1. Recipient phone app receives a call from +34567890123
> 
> 2. Recipient phone app sends an RCS to +34567890123 saying 'hello RCS client,
> I'm +34xxxxxxxxx, are you calling me?'
> 
> 3. Sending phone RCS app sends an RCS back saying 'yes, I'm currently calling
> you now' or 'no, I'm not calling you right now'
> 
> 4.  If recipient gets the 'yes' RCS they display a green tick, if they get a
> 'no' they display a 'suspicious incoming call' message and maybe block it. 
> If they don't get an answer they don't display anything.
> 
> That could be done automatically without the sender having to do anything.
> 
> If someone is spoofing numbers they aren't receiving messages on them, so
> the RCS will go to the genuine number owner, rather than the one doing the
> spoofing.
> 
> The trouble is that calls from iPhones or from businesses won't operate
> this system, so it doesn't actually help very much.  And even if iPhones do
> adopt it, it seems unlikely that businesses will, since business telecoms is
> mostly SIP based and has nothing to do with RCS.
> 
> Theo

SMS texts can be delayed, sometimes for minutes, or longer.

Is RCS *guaranteed* to be immediate, like before any ringing, or during
the first ring on the callee's phone?  It would have to be as
instantaneous as is Caller ID to be usable to verify the authenticity of
the Caller ID.  This RCS scheme is to validate Caller ID to thwart
spoofing.  CID occurs between the 1st and 2nd ring.  This RCS scheme
would have to prelude that lookup.  Anytime later means the callee sees
the proposed CID before it was validated.

I've read where RCS messages can take 20 minutes or hours to arrive
versus SMS that takes seconds or minutes?  In either case, any setup
using RCS would have to terminate that mode of authentication if it did
not complete just before or during the 1st ring at the callee.
For the proposed setup to work, the callee's RCS message to the caller
would need to get an immediate RCS response from the caller.  

The article says "When the call rings on the recipient, the mobile sends
an encrypted RCS message to the mobile phone of the legitimate owner of
the number to ask if they are really calling at that moment."  But is
RCS actually a real-time (instantaneous) messaging system?  Not from
what I've read, so far.

"The idea is interesting, since it does not use OTT data traffic, but
the services of the core of the network, which makes the exchange of
information faster and more reliable."

That is the hope.  Not a guarantee the scheme accomplishes the
validation BEFORE the Caller ID is presented to the callee.  Faster and
more reliable is still not a guarantee.

It isn't just the caller and callee that must both use the RCS scheme to
validate Caller ID.  The caller must be in a searchable database by
their provider to do the lookup by the callee's service provider.  Both
callee and caller must be using a phone app that incorporates the RCS
scheme for CID validation.  The caller, if spoofed, must have their
phone powered on to send the RCS response.  If the spoofed caller's
phone is off, it obviously cannot respond, but also as obvious is they
couldn't be making the call.  

The telcos for both caller and callee must support RCS.  Is RCS actually
so prevalent that all telcos support RCS?  That is, does every VOIP,
landline, and cellular provider for both major carriers and also all
MVNOs (Mobile Virtual Network Operators) now support RCS?

Will the callee's phone only ring after the RCS validation has
succeeded, and ensure the succeeding Caller ID is validated?  If RCS is
employed before the phone rings, could be the caller has to wait for RCS
to work at the callee, for the request for response via RCS reaches the
caller, and for the caller to send back a RCS response.  While all this
might happen in half a second under ideal conditions, again, is RCS
*always* guaranteed, and guaranteed instantaneous?

The criteria states both caller and callee be using phone apps that
incorporate the RCS validation scheme.  First limitation.  Both parties
must be using an Android phone.  Second limitation.  Excludes all the
iPhone users, and makes an easy circumvent by spammers.

There are many phone numbers you cannot dial.  While you may have a
direct phone number to your doctor, or his office, or your health plan,
those also have internal phones that you can never reach.  You cannot
call them on those numbers.  How about all those robocallers that aren't
for spam, but legitimate use, like your doctor's office making a
robocall as a reminder for an upcoming appointment.  Very unlikely RCS,
or any type of chatting, will be setup at those servers.

This is a stab in the right direction to help callees reduce spam and
phish calls, but it seems geared to a small subset of all callers.  The
premise is something is better than nothing, but not if its benefits are
outweighed by its interference.  It also puts the onus upon users
instead of placing it where it belongs: at the telcos.  In the long
past, users had to employ client-side anti-spam filtering to get rid of
all the crap showing up in their Inboxes.  Then e-mail providers started
adding their own server-side anti-spam filters.  Took a while before
they were more effective than local solutions.  Now I no longer need a
client-side anti-spam filter.  This RCS scheme seems to follow the same
pattern: make the users handle the problem, and maybe the telcos will do
the job they've promised for a long time.

The RCS validation of Caller ID may provide some benefit, but I see it
can also cause a lot of false positives.  Just because someone calls you
whether a human or robocaller doesn't mean they will issue an RCS
response, that they even could, that your and their telco supports RCS,
and all this is before when Caller ID is presented at your phone.

Road spikes can impede a fleeing felon in a car, but is not guaranteed
to stop the car.  The escapee could be driving a semi or bus.  X-Net is
better and safer as it wraps around and siezes the front wheels.  Both
are still useful, but not effective a rising road-embedded pillars yet
those don't work on motorcycles or bicycles.  

Any POCs (Proof Of Concept) testing on this RCS scheme yet?

We can attempt reduction using client-side solutions, but are still
allowing the spoofing services to continue operating.  Once those are
made illegal, and globally, CID spoofing will severely wane.

[toc] | [prev] | [next] | [standalone]

#154136

On 2026-06-12 03:18, VanguardLH wrote:
> Theo <theom+news@chiark.greenend.org.uk> wrote:
> 
>> VanguardLH <V@nguard.lh> wrote:
>>> "Carlos E.R." <robin_listas@es.invalid> wrote:

...

> "The idea is interesting, since it does not use OTT data traffic, but
> the services of the core of the network, which makes the exchange of
> information faster and more reliable."
> 
> That is the hope.  Not a guarantee the scheme accomplishes the
> validation BEFORE the Caller ID is presented to the callee.  Faster and
> more reliable is still not a guarantee.
> 
> It isn't just the caller and callee that must both use the RCS scheme to
> validate Caller ID.  The caller must be in a searchable database by
> their provider to do the lookup by the callee's service provider. 

I don't see why?

> Both
> callee and caller must be using a phone app that incorporates the RCS
> scheme for CID validation.  

The Google default app.

> The caller, if spoofed, must have their
> phone powered on to send the RCS response.  If the spoofed caller's
> phone is off, it obviously cannot respond, but also as obvious is they
> couldn't be making the call.
> 
> The telcos for both caller and callee must support RCS.  Is RCS actually
> so prevalent that all telcos support RCS?  That is, does every VOIP,
> landline, and cellular provider for both major carriers and also all
> MVNOs (Mobile Virtual Network Operators) now support RCS?
> 

Mobile phones only, AFAIK.

...


> Any POCs (Proof Of Concept) testing on this RCS scheme yet?

This is the field testing now :-)

> 
> We can attempt reduction using client-side solutions, but are still
> allowing the spoofing services to continue operating.  Once those are
> made illegal, and globally, CID spoofing will severely wane.


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154140

"Carlos E.R." <robin_listas@es.invalid> wrote:

> VanguardLH wrote:
>
>> It isn't just the caller and callee that must both use the RCS scheme to
>> validate Caller ID.  The caller must be in a searchable database by
>> their provider to do the lookup by the callee's service provider. 
> 
> I don't see why?

Isn't this whole RCS scheme to validate the Caller ID which is what is
getting spoofed?  The caller isn't being spoofed.  It's the CID they
send that could be spoofed.

Not everyone that calls has a CID.  They may elect to be anonymous, but
then the callee can choose to reject anonymous calls.

I use Google Voice: a VOIP service with PBX features.  Outgoing calls
made through Google Voice will have no CID to the callee.  That is,
Google Voice does not support the use of outgoing CNAM (Caller ID Name),
so the callee only sees my GV phone number.  Those that know my
long-time phone number will recognize it, or have already added me to
their contacts, so CID is superfluous.  GV sends state, city, unknown
caller, or possible spam as the CNAM to the callee, but the callee also
gets my phone number.  When someone calls my GV number, they call GV,
not my phone through its carrier.  They connect to GV which calls all my
phones (work, home, cell phones), like a PBX, by using simultaneous
ring.  Whichever of my phones I pick up gets the call.  I can switch
between phones by having GV ring a different phone to transfer the call.
I doubt any of this RCS scheme is going to work through GV since I doubt
GV will step out of the way to get the RCS request from my phone to the
caller, and the caller's RCS response back to my phone.  

Possibly it could work since GV passes the call to whichever phone I
pickup the call across all my phones getting the synchronous ring;
however, since there can be multiple phones getting rung by GV, just
which phone is going to send the RCS request to validate the caller?
Luckily with GV's anti-spam filtering, and call screening enabled, I
rarely get bogus calls, or spam calls, or wrong-dial calls.

I have had to make outbound calls using my cellular carrier since some
destinations refuse to accept calls from GV, or from any service other
than a major carrier or telco.  I cannot call someplace using GV, but
using my cellular carrier works.  That happens so rarely that it's like
I got caught with my snake in the pants zipper, and have to figure out
how to extricate myself from the situation: a painful occurrence that
hopefully happens VERY rarely.

>> Both callee and caller must be using a phone app that incorporates
>> the RCS scheme for CID validation.  
> 
> The Google default app.

For everyone other than Pixel users, that means having to install
Google's Phone app.  Most all other phones come bundled with whatever
Phone app the phone makers wanted to bundle on their phones in their
constant customizing to brand-mark their phones.

>> The telcos for both caller and callee must support RCS.  Is RCS actually
>> so prevalent that all telcos support RCS?  That is, does every VOIP,
>> landline, and cellular provider for both major carriers and also all
>> MVNOs (Mobile Virtual Network Operators) now support RCS?
> 
> Mobile phones only, AFAIK.

Android. Google's Phone app (when updated). Cellular carrier must
support RCS.  Nothing like GV in the route between caller and callee;
i.e., direct connect between endpoint mobile phones.  

>> Any POCs (Proof Of Concept) testing on this RCS scheme yet?
> 
> This is the field testing now :-)

"This feature is first rolling out to Pixel devices running Android 12
and above, but Google has released it as an open standard so that other
phone apps and operating systems can use it, so that in the future it
would be possible to validate numbers between Android and iOS if those
involved want."

Android 12 came out October 2021.  RCS got supported back in Android 6,
and later, but maybe now there are more RCS functions, like extensions
to RCS, that upped the minimum Android version.

No explanation why it must be a Pixel phone.  Google is delivering this
as an open standard hence there'll be some specs on it for use with
other phone apps.  Seems ANY non-Pixel phone running Android 12+ could
install the updated Google Phone app when it shows up.

The Google Phone app was released back in 2015.  I have a Samsung phone,
not a Pixel, so the Phone app on my phone is the one Samsung bundles on
their phones.  Was contemplating investigating Google's Phone app as a
replacement, but I'm not impressed with its reviews.  I've had none of
the difficulties with the Samsung Phone app that are noted by the 1-star
Play Store reviews on Google's Phone app with way too many within the
last year than I'm going to bother to count, and it's been out for over
10 years now.  Guess I'll pass on whatever extras Google's Phone app
might've given me to opt for stability.

[toc] | [prev] | [next] | [standalone]

#154146

VanguardLH wrote:

> Isn't this whole RCS scheme to validate the Caller ID which is what is
> getting spoofed?  The caller isn't being spoofed.  It's the CID they
> send that could be spoofed.

Apparently the scammers *are* faking the voice as well as the caller ID.

So you get a call from an AI version of your relative, saying they've 
been robbed while on holiday, asking if could you send them some money 
so they can get home again ... enough people fall for this when it's 
just faked email/text.

[toc] | [prev] | [next] | [standalone]

#154149

Andy Burns <usenet@andyburns.uk> wrote:

> VanguardLH wrote:
> 
>> Isn't this whole RCS scheme to validate the Caller ID which is what is
>> getting spoofed?  The caller isn't being spoofed.  It's the CID they
>> send that could be spoofed.
> 
> Apparently the scammers *are* faking the voice as well as the caller ID.
> 
> So you get a call from an AI version of your relative, saying they've 
> been robbed while on holiday, asking if could you send them some money 
> so they can get home again ... enough people fall for this when it's 
> just faked email/text.

https://signalwire.com/blogs/industry/caller-id-vs-cnam

I thought just CNAM (Caller ID Name) was getting spoofed.  Apparently
the phone number, part of Caller ID, can be spoofed, too.  More
pernicious than I knew.

https://en.wikipedia.org/wiki/Caller_ID_spoofing
  "Starting in mid-2017, the FCC pushed forward Caller ID certification 
  implemented using a framework known as STIR/SHAKEN.[45][46] 
  SHAKEN/STIR are acronyms for Signature-based Handling of Asserted 
  Information Using toKENs (SHAKEN) and the Secure Telephone Identity 
  Revisited (STIR) standards. The FCC has mandated that telecom 
  providers implement STIR/SHAKEN-based caller ID attestation in the IP   
  portions of their networks beginning no later than June 30, 2021."

  "Congress passed the TRACED Act in 2019 which makes Caller ID 
  authentication mandatory."

https://en.wikipedia.org/wiki/STIR/SHAKEN

That was over 5 year ago (2021) for large providers with over 100K
subscribers, and 3 years ago (2023) for providers with under 100K
subscribers (e.g., C Spire).  These are service-side measures.  Nothing
needed on your end.

https://techoutreach.extension.msstate.edu/news/2022/04/take-steps-avoid-caller-id-spoofing-scams
  "The SHAKEN/STIR caller ID authentication system is also stopping many 
  unwanted calls from being completed. These acronyms stand for 
  Signature-based Handling of Asserted Information using toKENs and the 
  Secure Telephone Identity Revisited standards. The system allows a 
  phone number to be verified by both the carrier from which the call is 
  placed and the carrier receiving the call."

If these service-side measures worked, why would Google be trying to
come up with an alternative client-side validation scheme using RCS to
attest the caller of a call?

All of this is to eliminate spoofed calls, not specifically to eliminate
spam calls initiated by humans or robocallers.  However, if *no* spoofed
calls could complete a connection to a callee, then block lists of bad
phone numbers would be feasible, and not end up blocking innocents that
were spoofed.

[toc] | [prev] | [next] | [standalone]

#154151

On 13.06.26 22:52, VanguardLH wrote:
> Apparently
> the phone number, part of Caller ID, can be spoofed, too. 

This is the real issue and nothing else.

-- 
"Roma locuta, causa finita" (Augustinus)

[toc] | [prev] | [next] | [standalone]

#154135

On 11.06.26 23:32, Theo wrote:
> The trouble is that calls from iPhones or from businesses won't operate
> this system, so it doesn't actually help very much.  And even if iPhones do
> adopt it, it seems unlikely that businesses will, since business telecoms is
> mostly SIP based and has nothing to do with RCS.

+1


-- 
"Roma locuta, causa finita" (Augustinus)

[toc] | [prev] | [next] | [standalone]

#154137

On 2026-06-11 23:32, Theo wrote:
> VanguardLH <V@nguard.lh> wrote:
>> "Carlos E.R." <robin_listas@es.invalid> wrote:
>>> Translated with DeepL.com (free version)
>>
>> So the non-spoofed caller makes their call, and then has to respond to a
>> text message?  Oh joy, 2FA comes to voice calls, too.
> 
> I was assuming that it's making an automatic handshake with the calling
> phone via RCS, not asking the caller to do it.
> 
> ie:
> 1. Recipient phone app receives a call from +34567890123
> 
> 2. Recipient phone app sends an RCS to +34567890123 saying 'hello RCS client,
> I'm +34xxxxxxxxx, are you calling me?'
> 
> 3. Sending phone RCS app sends an RCS back saying 'yes, I'm currently calling
> you now' or 'no, I'm not calling you right now'

Ah, automated. I thought it was the user typing. Now it makes sense. So 
they are doing a handshake without having a protocol designed for this. 
Mmm. Next step would be upgrading the entire network to do a handshake 
on all calls.

> 
> 4.  If recipient gets the 'yes' RCS they display a green tick, if they get a
> 'no' they display a 'suspicious incoming call' message and maybe block it.
> If they don't get an answer they don't display anything.
> 
> That could be done automatically without the sender having to do anything.
> 
> If someone is spoofing numbers they aren't receiving messages on them, so
> the RCS will go to the genuine number owner, rather than the one doing the
> spoofing.
> 
> The trouble is that calls from iPhones or from businesses won't operate
> this system, so it doesn't actually help very much.  And even if iPhones do
> adopt it, it seems unlikely that businesses will, since business telecoms is
> mostly SIP based and has nothing to do with RCS.
> 
> Theo


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154141

"Carlos E.R." <robin_listas@es.invalid> wrote:

> Ah, automated. I thought it was the user typing. Now it makes sense.
> So they are doing a handshake without having a protocol designed for
> this. Mmm. Next step would be upgrading the entire network to do a
> handshake on all calls.

The core RCS scheme to validate the caller would have to be faster than
delivery of the CNAM (Caller ID Name) data sent to the callee's phone
since the RCS scheme is to validate CNAM.  What good would be validating
the caller's CNAM that has already been presented to the callee?

CNAM can be spoofed.  How about the caller's phone number?

"Google has released it as an open standard so that other phone apps and
operating systems can use it."

Google will publish the protocol, but this is a client-side solution,
not up at the mobile carrier.  Upstream at the carrier would be prefered
to eliminate any minimum requirements at the callee's end: minimum
Android version, Pixel but don't know why that hardware is required, and
Google's Phone app.  The only requirement for the mobile carrier is they
support RCS.  

Is RCS now ubiquitous across *all* mobile carriers?  RCS is carrier
dependent.  Google has no control over whether or not carriers have RCS.

https://www.braze.com/resources/articles/future-of-rcs-vs-sms#h-758d433902f8
"As with MMS, if a message cannot be delivered via RCS (because either
the carrier or device does not support it), it will be delivered via SMS
by default."

Uffdah.  If the fallback is to SMS, forget about transparency in this
RCS-validate-CNAM scheme.  SMS texts would never arrive before CNAM was
presented to the callee.  Ever have to wait for a 2FA code sent by SMS
to complete a login?  Sure you have.  I've even had to resend the 2FA
code via SMS, because their SMS server didn't send me the code, or it
never arrived.  Would you tolerate that unreliable (nonguaranteed
delivery) scheme with exhorbitant delays after your phone starts
ringing?

Long ago, I had to employ client-side anti-spam filtering.  More
overhead and maintenance for me.  Been a long time since anti-spam
filtering has been more than satisfactory for me up on the server.  I
even prefer to define my e-mail filters on the server instead of in my
local e-mail client, but it took even longer for e-mail providers to
have a decent set of server-side rules to eliminate doing it at the
client end.  

If this RCS scheme to validate CNAM works well, with high reliability,
and with almost zero latency to ensure the CNAM validate completes
before the callee ever sees it, and Google's protocol gets adopted by
other phone apps, especially those bundled by phone makers, then maybe
the mobile carriers will implement this as a standard upstream feature
in their service.  After all, they'll probably save on reduced support
calls from their customers.  They could even advertise it as "Come to us
with our free anti-spoof feature" for a marketing edge.  I suspect it
will be many years before CNAM-validate-by-RCS will become a standard
service feature, or carriers may get greedy by charging their customers
for the extra anti-spoof feature, or include it in a paid business-tier
service plan.  Money money money.

Another cripple point: SMS doesn't require [cellular] data service.  No
data or wifi needed for SMS.  RCS does require data or wifi.  So this
scheme attempts to meld phone calls with messaging.  I know folks that
have unlimited calling, but with limited data, or they have mobile
service for calls but no data included.  Although RCS was designed for
rich content, this anti-spoofing scheme should have tiny messages, but
LOTS of calls means a lot more data usage.  Then there are folks that
don't have any mobile service.  They use their smartphone with a wifi
hotspot, like their wifi cable modem at home, or at cafes, libraries,
etc.  Even with data over wifi, someone driving in a car will make (if
auto is enabled) and break wifi connections too fast as they're zooming
down the street past Starbucks*.  Versus mobile data that is designed to
switch between towers the same as for mobile calls.

* Of course, they shouldn't be doing calls while driving, but we all
know that happens.  While driving, they could stop to park right in
front on Starbucks hoping to be close enough to get enough signal
strength from the hotspot for wifi data.

[toc] | [prev] | [next] | [standalone]

#154145

Theo <theom+news@chiark.greenend.org.uk> wrote:
> VanguardLH <V@nguard.lh> wrote:
> > "Carlos E.R." <robin_listas@es.invalid> wrote:
> > > Translated with DeepL.com (free version)
> > 
> > So the non-spoofed caller makes their call, and then has to respond to a
> > text message?  Oh joy, 2FA comes to voice calls, too.
> 
> I was assuming that it's making an automatic handshake with the calling
> phone via RCS, not asking the caller to do it.

I was almost there, but got it wrong that the verifying RCS message is sent along
with the call - it's only initiated by the recipient if it didn't get the
initial RCS verification:

https://blog.google/security/android-fake-call-detection/

They're selling it as preventing deepfakes where the attacker can both spoof
a number and spoof that person's voice, making it hard to tell from the real
person.  In that case I can see why something to assert it wasn't the real
phone comes in useful.

It's quite a narrow use case (just spoofed calls from people you know,
rather then spoofed calls from your bank/etc, and not Facetime/Whatsapp/... 
voice calls) but I suppose phone calls are where the scammers are striking,
so it makes sense to start there.

Theo

[toc] | [prev] | [next] | [standalone]

#154154

On 2026-06-13 00:11, Theo wrote:
> Theo <theom+news@chiark.greenend.org.uk> wrote:
>> VanguardLH <V@nguard.lh> wrote:
>>> "Carlos E.R." <robin_listas@es.invalid> wrote:
>>>> Translated with DeepL.com (free version)
>>>
>>> So the non-spoofed caller makes their call, and then has to respond to a
>>> text message?  Oh joy, 2FA comes to voice calls, too.
>>
>> I was assuming that it's making an automatic handshake with the calling
>> phone via RCS, not asking the caller to do it.
> 
> I was almost there, but got it wrong that the verifying RCS message is sent along
> with the call - it's only initiated by the recipient if it didn't get the
> initial RCS verification:
> 
> https://blog.google/security/android-fake-call-detection/

Can we ensure that the bad caller can not also send a fake RCS message?

> 
> They're selling it as preventing deepfakes where the attacker can both spoof
> a number and spoof that person's voice, making it hard to tell from the real
> person.  In that case I can see why something to assert it wasn't the real
> phone comes in useful.
> 
> It's quite a narrow use case (just spoofed calls from people you know,
> rather then spoofed calls from your bank/etc, and not Facetime/Whatsapp/...
> voice calls) but I suppose phone calls are where the scammers are striking,
> so it makes sense to start there.
> 
> Theo


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154158

"Carlos E. R." <robin_listas@es.invalid> wrote:

> Can we ensure that the bad caller can not also send a fake RCS message?

If the scammer is making the call, and it's not some robocaller frontend
that cannot be called back nor responds to RCS messages, and the scammer
spoofs their phone number, the callee's RCS message goes to the spoofed
number, not back to the scammer.

spammer @ 123-456-7890 --> spoof 567-890-1234 --> callee sends RCS --.
                                 \__________/                        |
                                      ^______________________________|
                                 
Since the scammer doesn't get the "are you there" RCS message, the
scammer cannot send an RCS response to the callee.  They cannot send a
fake RCS ACK to the callee, because they never got the RCS REQ from the
callee.

There are situations in which a spoofed number is legal, and actually
mandatory.  Say a doctor wants to call a patient regarding a test
result.  He calls the patient on his phone, but doesn't take direct
calls from patients.  His personal phone couldn't handle the load of all
his patients calling him.  Instead he wants them to call his office to
handle, process, and forward incoming calls to him.

If the spoofed number is controlled by the caller, that number could
send an RCS response to make the callee happy that the spoofed number
was the caller.  This is the situation where spoofing is legal.  The
caller uses a phone that does not take outside calls, or any calls.  It
is an outbound-only number.  The spoofed number points the callee at an
office for the caller, a call center, support center, customer service,
the front desk at a pharmacy, etc.

I use Google Voice, and it spoofs my phone number.  When I make calls
through GV, the callee sees my GV number, not the one for my landline at
home or work, or one of my mobile phones all of which have different
real phone numbers (i.e., the one with the telco or mobile carrier).

     real mobile #          my GV number
me @ 123-456-7890 --> spoof 789-012-3456 --> callee sends RCS --.
                            \__________/  break                 |
                                 ^________~  ~__________________|
                                 
Although Google is promoting their RCS-caller-validation scheme, I doubt
their Google Voice service will respond to RCS requests by the callee.
To the callee, it tries to send an RCS message to my GV number, but GV
doesn't send back an RCS response.

GV will forward SMS texts to my real phones, and even e-mail me a
transcript of them, but I don't how the RCS messages will be handled.
GV does forward regular RCS messages to my real phone, but the RCS
validation scheme proposes to use "special" messages that the Phone app
automatically handles for an automated response.  If the special RCS
messages get through my GV account just as do SMS texts, it would
something like:

     real mobile #          my GV number
me @ 123-456-7890 --> spoof 789-012-3456 --> callee sends RCS --.
     \__________/<----------\__________/<-----------------------'
          '------------ RCS ACK -----------> callee

However, the RCS ACK from my real phone will be for my real phone
number, not the spoofed number from my GV account.  The caller will see
a mismatch between the GV spoofed number and my real phone number on my
actual phone.  If GV sends the RCS ACK, the caller sees and verifies the
spoofed number called them.  If GV merely passes the RCS REQ through GV
to my real phone, the callee sees a mismatch.  They know my GV number is
spoofed, but that is exactly how PBX systems worked: many internal
publicly-inaccessible numbers piped in and out through one externally
publicly-accessible number.  For me, and for the RCS validation scheme
to work, Google would also have to deploy their RCS validation protocol
at the Google Service itself, so it can send the RCS ACK to the callee,
and the callee sees the ACK came from the same GV spoofed number
originally given the callee.  That's why I say there will many scenarios
that are legit that Google will have to amend their RCS scheme, like
providing registrations for PBX, VOIP, and other service providers where
the caller isn't trying to hide, or where spoofed number are completely
legal.

Just like GV would have to add handling of incoming RCS REQs coming from
callees receiving GV outbound calls, seems easy enough for spoofing
providers (those that don't care about intent regarding use) to also
incorporate the RCS ACK in Google's RCS validation scheme.  The callee
sends an RCS REQ to the spoofed number, the spoofing service sends back
an RCS ACK, and the callee is happy that the Caller ID number shown to
them is the caller's phone number.  Again, there are legit uses of
spoofing.  It's the scammy (illegal) uses of spoofing that are a
problem.

The way the law is written is not to totally bar the use of spoofing,
but to make illegal the use of spoofing to collect info or falsely
respresent the caller to cause [financial] harm to the callee, or
attempt to phish, or otherwise collect sensitive information that could
harm the callee.  The laws don't make spoofing illegal.  They make
illegal some uses of spoofing.

[toc] | [prev] | [next] | [standalone]

#154159

On 2026-06-15 03:18, VanguardLH wrote:
> "Carlos E. R." <robin_listas@es.invalid> wrote:
> 
>> Can we ensure that the bad caller can not also send a fake RCS message?
> 
> If the scammer is making the call, and it's not some robocaller frontend
> that cannot be called back nor responds to RCS messages, and the scammer
> spoofs their phone number, the callee's RCS message goes to the spoofed
> number, not back to the scammer.

You missed the part where the calling party also sends an RCS saying I'm 
calling you, before being asked.

If this initial message is missing, then the called party sends an rcs 
back. Thus not always.

> 
> spammer @ 123-456-7890 --> spoof 567-890-1234 --> callee sends RCS --.
>                                   \__________/                        |
>                                        ^______________________________|
>                                   
> Since the scammer doesn't get the "are you there" RCS message, the
> scammer cannot send an RCS response to the callee.  They cannot send a
> fake RCS ACK to the callee, because they never got the RCS REQ from the
> callee.
> 
> There are situations in which a spoofed number is legal, and actually
> mandatory.  Say a doctor wants to call a patient regarding a test
> result.  He calls the patient on his phone, but doesn't take direct
> calls from patients.  His personal phone couldn't handle the load of all
> his patients calling him.  Instead he wants them to call his office to
> handle, process, and forward incoming calls to him.

Just call using the exchange at the clinic. He can have a mobile phone 
with a number handled by the exchange, but I have seen this only on big 
places.

...

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154164

"Carlos E. R." <robin_listas@es.invalid> wrote:

> You missed the part where the calling party also sends an RCS saying I'm 
> calling you, before being asked.
> 
> If this initial message is missing, then the called party sends an rcs 
> back. Thus not always.

My understanding is the RCS validation is callee initialized, not caller
initialized.  I would think the scheme would not have the callee
accepting an RCS ACK before it even sent its own RCS REQ.

The article mentioned Google's open standard, but did not provide a URL
to it.  Looks like the scheme uses encrypted RCS messaging.  The
callee's Phone by Google app would have to initiate the encrypted RCS
messaging.  It's not going to listen for an RCS ACK message until the
callee initiates with an RCS REQ.

https://blog.google/security/android-fake-call-detection/

But still no link to the definition of their open protocol.

https://www.techtimes.com/articles/318000/20260608/android-fake-call-detection-targets-ai-deepfakes-rcs-handshake-verifies-caller-devices.htm
"When a saved contact calls, their Phone by Google app sends a silent,
real-time cryptographic confirmation token over the RCS signaling layer
to the recipient's device. That token confirms the call is genuinely
originating from the contact's registered hardware — not routed through
VoIP software with a spoofed caller ID."

Hmm, so the caller initiates with sending an encrypted RCS token to the
callee.  But all of this RCS attestation is only for saved contacts.
Your phone sees a number you saved as a contact for Mom, and uses the
RCS token to verify it's Mom.  However, if you don't have a contact for
Mom, the caller ID says "Mom", and RCS attestation isn't involved.
Doesn't seem a reliably or trustworthy scheme if the caller initiates
the RCS attestation.

"There is one meaningful constraint: both the caller and the recipient
must be using Phone by Google with RCS active [and the mobile carriers
by both parties must support RCS], alongside Google Contacts and Google
Messages. Users whose carriers installed a different default dialer can
install Phone by Google from the Google Play Store and set it as the
default to enable protection."
(I added the bracketed content.)

How many spammers, scammers, or phishers are going to use the Phone by
Google app to make calls?  None.  The prime assailants won't be using
the Phone by Google app, so none of the RCS scheme gets employed.
Google hopes their open standard (wherever it may be defined) gets
adopted by other phone app authors, but that's wishful thinking, and
would take a while, anyway.

Seems this RCS attestation scheme is limited to a select few users.  If
the caller doesn't have RCS (or you don't) with your mobile carrier, the
scheme is dead.  If the caller doesn't use the Phone by Google app, the
scheme is dead until if and when the dev for whatever phone app you use
incorporates this scheme. The scheme doesn't look to cover non-contact
callers; i.e., it validates the Caller ID matches a contact, but if the
caller isn't a contact then there is no validation.  I was hoping the
scheme would address any spoofed caller, not just spoofed callers trying
to imitate an entry in your Contacts.

https://www.makeuseof.com/android-fake-call-detection-how-it-works/

From the image, the assumption is the scammer doesn't send the
confirmation signal via encrypted RCS.  Maybe that is how it not works
at the spoofing services used by scammers, but obviously the spoofing
services could also implement the RCS scheme by pretending, for now,
they are using the Phone by Google app.

Imposter makes a call pretending to be Mom, and includes the RCS
confirmation signal.  You get the spoofed call, and your phone app
checks with Mom's device using RCS.  Might work if Mom's phone was
powered up to respond.  Maybe it isn't.  If the imposter pretends to be
not just your pharmacy, but the distro warehouse for your pharmacy, you
won't have them as a contact (you won't even know their phone number).
Caller isn't a contact, so this RCS scheme is dead.  A caller that is
not a saved contact isn't challenged to prove they are who they say.  I
wasn't aware that spoofing primarily targeted saved contacts on the
callee's phone.  How are they going to get my contacts?

This seems a stab at an iffy scenario for limited subset of users, and
likely to fade away if STIR/SHAKEN gets adopted by all mobile carriers,
and actually works.  However, its just for mobile calls.  Apparently
Google isn't keen on STIR/SHAKEN, and came up with a client-end scheme
that bypasses any spoof checking at the carrier.

Gotta have this, gotta have that, and something else, too, and only for
some callers, which means the typical user won't know what it isn't
working.  I don't see this as some Earth shaking improvement in
thwarting spoofed calls with untoward intent.  Seems more likely it will
interfere with legitimately spoofed callers.

[toc] | [prev] | [next] | [standalone]

#154165

VanguardLH <V@nguard.lh> wrote:
> initialized.  I would think the scheme would not have the callee
> accepting an RCS ACK before it even sent its own RCS REQ.
> 
> The article mentioned Google's open standard, but did not provide a URL
> to it.  Looks like the scheme uses encrypted RCS messaging.  The
> callee's Phone by Google app would have to initiate the encrypted RCS
> messaging.  It's not going to listen for an RCS ACK message until the
> callee initiates with an RCS REQ.
> 
> https://blog.google/security/android-fake-call-detection/
> 
> But still no link to the definition of their open protocol.
> 
> https://www.techtimes.com/articles/318000/20260608/android-fake-call-detection-targets-ai-deepfakes-rcs-handshake-verifies-caller-devices.htm
> "When a saved contact calls, their Phone by Google app sends a silent,
> real-time cryptographic confirmation token over the RCS signaling layer
> to the recipient's device. That token confirms the call is genuinely
> originating from the contact's registered hardware — not routed through
> VoIP software with a spoofed caller ID."
> 
> Hmm, so the caller initiates with sending an encrypted RCS token to the
> callee.  But all of this RCS attestation is only for saved contacts.
> Your phone sees a number you saved as a contact for Mom, and uses the
> RCS token to verify it's Mom.  However, if you don't have a contact for
> Mom, the caller ID says "Mom", and RCS attestation isn't involved.
> Doesn't seem a reliably or trustworthy scheme if the caller initiates
> the RCS attestation.

It seems this is a byproduct of end to end encryption over RCS.  As part of
starting an RCS conversation a set of key pairs are established.  Then you
can use those to securely communicate with your correspondent.

In this case the 'I'm calling you' RCS message is presumably using the
existing key pairs, meaning that secure communication is already established. 
In that way you can know that a call you receive from your correspondent
without the accompanying RCS message is more likely to be spoofed, and the
warning message displayed.

For a contact who you haven't previously established RCS communication with,
the system hasn't yet established a secure channel.  I'm not sure if you can
send an unsolicited RCS message anyway; presumably businesses must be able
to send out RCS messages without having the user enroll them as contacts
first?  But presumably if you don't have a key pair established then you
can't put up a message saying the call is suspicious?

The place I can see this falling down is where you have never contacted them
via RCS, only phone calls or other means.  For example if you always chat
with grandma via iMessage or WhatsApp then you may not have established an
RCS session with her to set up keys.  Then the phone can't know whether she
is on RCS or not (without some potentially slow discovery process) and can't
pop up a message saying not to trust the call.

> Imposter makes a call pretending to be Mom, and includes the RCS
> confirmation signal.  You get the spoofed call, and your phone app
> checks with Mom's device using RCS.  Might work if Mom's phone was
> powered up to respond.  Maybe it isn't.  If the imposter pretends to be
> not just your pharmacy, but the distro warehouse for your pharmacy, you
> won't have them as a contact (you won't even know their phone number).
> Caller isn't a contact, so this RCS scheme is dead.  A caller that is
> not a saved contact isn't challenged to prove they are who they say.  I
> wasn't aware that spoofing primarily targeted saved contacts on the
> callee's phone.  How are they going to get my contacts?

I don't think it's saved contacts that is relevant, it's people you have
already contacted via RCS.  That is mostly people with real mobile
phones, rather than landlines or businesses.

> This seems a stab at an iffy scenario for limited subset of users, and
> likely to fade away if STIR/SHAKEN gets adopted by all mobile carriers,
> and actually works.  However, its just for mobile calls.  Apparently
> Google isn't keen on STIR/SHAKEN, and came up with a client-end scheme
> that bypasses any spoof checking at the carrier.

STIR/SHAKEN is a US thing, it doesn't apply in other countries.  Google's
solution does.

Theo

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.mobile.android

csiph-web