Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Carlos E. R." Newsgroups: comp.mobile.android Subject: Re: Android will detect calls with spoofed numbers by sending a real-time RCS message to the legitimate owner Date: Mon, 15 Jun 2026 21:21:41 +0200 Lines: 95 Message-ID: References: <08onfmxrah.ln2@Telcontar.valinor> <1qwv27zsc5bmc$.dlg@v.nguard.lh> <+7F*BAaJA@news.chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net 31k6vxId4hFZcAhBL5tXdgq3BfQ5SGSaNSFN2XVgvLspeLaDkk Cancel-Lock: sha1:vbDA4cqMvUWTgOouoktnNsZVXbo= sha256:apQSVrUIMYlCo4Uacs7EmYpDbCfxfU+RJcFNRc+LCUw= User-Agent: Mozilla Thunderbird Content-Language: en-GB In-Reply-To: <+7F*BAaJA@news.chiark.greenend.org.uk> Xref: csiph.com comp.mobile.android:154170 On 2026-06-15 17:29, Theo wrote: > VanguardLH 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. Ah. So this is the answer to my question, thanks. > > 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? In this case, and grandma below, side B messages side A. > > 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. > Right. >> 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 It is a start. -- Cheers, Carlos E.R. ES🇪🇸, EU🇪🇺;