Branded calls mediante Rich Call Data (RCD) sobre STIR /Shaken
RCD una extensión de STIR/SHAKEN para añadir información de marca a las llamadas
Podemos definir a las branded calls sobre STIR/SHAKEN como la primera solución de red de operador en ofrecer branded calls, sin necesidad de aplicaciones de terceros en los terminales.
Esta es la estrategia implementada en Estados Unidos gracias al empuje de la CTIA y su ecosistema Branded Call ID.
¿Por qué combinar RCD con STIR/SHAKEN?
En el contexto de las branded calls, STIR/SHAKEN opera como un framework habilitador para el uso de Rich Call Data.
Técnicamente RDC (Rich Call Data) está definido como una extensión opcional del framework STIR/SHAKEN. Por lo que en el contexto de las branded calls no podemos concebir la existencia de RCD sin STIR /SHAKEN. Existen otros frameworks de basados en el uso de certificados y claves públicas que pueden ocupar un posicionamiento similar (P.e. VVC)
STIR/SHAKEN nos indica si el origen de la llamada ha sido verificado por el proveedor de servicios originante, mientras que RCD (Rich Call Data) permite adjuntar y entregar información adicional, como el nombre o logotipo de la empresa que realiza la llamada, desde una fuente confiable.
Por lo tanto esta combinación de STIR/ShAKEN y sus estándares con su extensión RCD (opcional, ya que se puede usar STIR/SHAKEN sin RCD), nos aporta una mayor seguridad y una experiencia de uso más completa en el proceso de llamada.
Características del Rich Call Data
Frente a otras opciones como CNAME, el RCD ofrece una estrategia muy diferente, entregando mallor control sobre la forma en la que se presenta su marca a la empresa originante y aportando una mayor fiabilidad a la información ofrecida al destinatario, apoyándose en las capas de verificación y seguridad asociadas a STIR/SHAKEN.
- La información es mantenida por el llamante y el proveedor de servicios de branded calling actúa como fuente única de confianza de dicha información.
- La información de marca se introduce en la llamada en el origen, en lugar de ser buscada al final.
- Forma parte de STIR/SHAKEN
- Se introduce en la llamada como parte del proceso de autenticación. Es incluída en el SHAKEN identity token y firmado digitalmente usando una PKI (Public Key Infrastructure).
- No puede ser modificada ni alterada.
- Además del nombre del llamante, incluye otros tipos de información como:
- Imagen o logo.
- Propósito de la llamada.
En el futuro, se espera también que esta solución permita seguir añadiendo nuevas capacidades, tales como añadir información contextual al historial de llamadas para informar a los usuarios después de que esta tenga lugar.
¿Por qué es más seguro el uso de RCD que otras opciones?
La seguridad asociada al RCD procede de un conjunto de capacidades técnicas tanto de los proveedores de servicio como de los fabricantes de dispositivos, y de una serie de procesos que implican tanto a las empresas, proveedores de servicios de branded calling y a los operadores en la autenticación de las llamadas.
Arquitectura de red para branded calling con RCD
¿Cuáles son los procesos claves en una arquitectura de branded calling basada en RCD?
Vetting
Los negocios deben trabajar con un partner que valide los números de teléfono que utiliza y que ese negocio tiene los permisos necesarios para utilizar dichas numeraciones (por ejemplo atendiendo a normativas existentes en relación al uso de determinadas numeraciones). Esta pre-certificación de los contenidos puede responder a motivaciones como:
- Requerimientos regulatorios.
- Acuerdos de servicios de atención al cliente.
- Políticas de las empresas, relacionadas con el uso de las marcas.
Autenticación mediante STIR/SHAKEN
Al recibir una llamada protegida con STIR/SHAKEN es posible examinar el token JWT PASSporT y determinar el nivel de confianza que se debe asignar al identificador de la llamada mostrada. Estos tokens se clasifican en tres niveles que determinan una mayor o menor confianza en el origen de llamada (A,B y C), conocidos como “attestation levels”.
Los tres niveles de “attestation” posibles son:
- “C” (gateway attestation): el operador solo sabe que la llamada entra en su red, sin verificar el origen.
- “A” (full attestation) el operador autentica el número y al usuario.
- “B” (partial attestation) el operador conoce al usuario, pero no el número.
JWT PASSporT
El PASSportT es un token de cifrado transportado por los “SIP identity headers” y certificados SSL, que son enviados a otros proveedores de servicio o entidades certificadoras para garantizar que la persona que llama es realmente quien dice ser.
De manera similar a como puedes utilizar un pasaporte para identificarse cuando se realiza un viaje, una llamada usa un PASSporT para verificarse. Este token actúa como vehículo para transportar de manera segura el RCD, el «attestation» level, u otros elementos criptográficos.
Integridad
Para garantizar que el contenido procede de fuentes fiables y no puede ser modificado, los operadores deben:
- Solicitar el contenido enriquecido a un proveedor de branded calls que haya verificado la autenticidad de la información que la marca (vetting) quiere mostrar .
- Hacer uso de los certificados que autentican la llamada y que permiten su verificación gracias a fuentes de confianza como son las autoridades certificadoras.
Al firmarse digitalmente el contenido en el origen de la llamada, se garantiza que toda la información que viaja en el JWT PASSporT no será modificada al pasar por los diferentes intermediarios (como operadores de tránsito) hasta llegar al operador terminante.
Vesper token
El “vesper” token introduce un mecanismo formal y un protocolo para representar informaciones verificadas durante el proceso de verificación de la identidad. Resuelve el desafío de la delegación de certificados, necesaria para que un tercero haga uso de un número de teléfono que no le pertenece (p.e. un contact center haciendo uso de un número de teléfono de una de las marcas para las que trabaja).
Permite garantizar que la entidad interesada en realizar la llamada tiene derecho a emplear un determinado número de teléfono. También se puede emplear para facilitar comprobaciones en procesos KYC/KYB y solicitudes de consentimiento.
Facilita la divulgación selectiva de información asociada a un número de teléfono, permitiendo a las entidades compartir detalles específicos con partes autorizadas manteniendo la privacidad.
Los tokens Vesper son un tipo específico de token definido dentro del marco STIR (Secure Telephony Identity Revisited).
RCDI (RCD Integrity)
En ocasiones es necesario que el contenido RCD sea transmitido fuera del JWT (por ejemplo para aligerar el peso del PASSporT). En esos casos, para garantizar la integridad del RCD, se incluye un hash criptográfico del documento RCD externo dentro del PASSporT, conocido como RCDI (RCD Integrity).
"rcdi": "sha256-7d6fd23fda7abc9e8b3..."Este hash asegura una relación directa entre el JWT y el RCD externo, garantizando que este último no ha sido modificado.
El objeto rcd puede viajar dentro del JWT firmado, o ser almacenado en un servidor externo (modo detached), localizable a través del header SIP call-info:
Call-Info: <https://cdn.ejemplo.com/rcd/123456.json>;purpose=infoEn este segundo caso, el operador terminante se descarga ese JSON, calcula su hash y lo compara con el rcdi proporcionado en el PASSport.
Uso de dispositivos compatibles
Los consumidores deben disponer de dispositivos capaces de renderizar la información RCD, para que esta sea mostrada en sus dispositivos.
En cualquier caso, esta presentación siempre estará supeditada a que el operador ofrezca este servicio, y a que exista un acuerdo entre fabricante y operador que permita mostrar información de marca al usuario final.
Los terminales (Android, IOS u otros terminales SIP) no leen directamente el PASSporT ni lo validan, por lo que esta desencriptación debe suceder en la red. El operador terminante debe validar el PASSport firmado (ATIS 1000094), y usará otras cabeceras SIP compatibles con los dispositivos, como propone draft-ietf-sipcore-callinfo-rcd-19 utilizando la cabecera-call info, para incluir en ella la información RCD necesaria en el último salto (entre operador terminante y dispositivo de usuario receptor).
¿Cuáles son las limitaciones de la extensión RCD de STIR/SHAKEN?
Dependencia del ecosistema STIR/Shaken
Es importante entender que RCD requiere STIR/SHAKEN. Si la llamada no está autenticada, firmada y verificada el RCD no puede ser utilizado.
Según un estudio de Transnexus (2024) sobre más de 900 telcos, apenas el 37% de las llamadas han sido firmadas.
Las limitaciones serán como mínimo las mismas que las del framework de autenticación:
- Arquitectura diseñada para Internet: solo funciona en redes SIP/IP (VoIP o VoLTE)
- No autentica el «displayed Caller ID»
- Carrier authentication technology
- Etiquetado erróneo
- Sistema de confianza delegada en un tercero
- Problemas de seguridad y privacidad de STIR/SHAKEN
- Penetración geográfica de STIR/SHAKEN
- Dificultades de adopción por parte de los operadores más pequeños
- Despliegue internacional limitado
- Actualmente, STIR/SHAKEN no es compatible con llamadas internacionales
- Tensiones geopolíticas e iniciativas soberanas
Algunos autores plantean la posibilidad de integrar protocolos Out-of-band (p.e. ATIS-1000096 propone un método para lograr que el PASSporT sobreviva a las llamadas mediante TDM ) para obtener un mecanismo de verificación equivalente para redes non-IP. Pero la contrapartida es que añade complejidad técnica al proceso.
