Autoridad de certificación STIR/SHAKEN y el ecosistema STI-CA

Cada llamada firmada en el marco STIR/SHAKEN lleva una firma criptográfica, y esa firma solo es confiable porque se remonta a un certificado que el operador de terminación puede verificar. Detrás de ese certificado hay una infraestructura de clave pública (PKI) pequeña y estrictamente gobernada: una autoridad de gobernanza que fija las reglas, un único administrador de políticas que las hace cumplir y una lista corta de autoridades de certificación aprobadas, que son las que realmente emiten los certificados. Si usted opera una red de voz en Estados Unidos, no puede firmar una llamada con ningún nivel de atestación hasta registrarse en este ecosistema y obtener su propio certificado.

Esta guía explica quiénes son los actores, cómo se articula la cadena de confianza y los pasos exactos que sigue un proveedor de servicios de voz para registrarse, obtener un token SPC (Service Provider Code) y recibir un certificado STI. También aborda la regla de certificado propio de la FCC, que redefinió lo que está permitido al “usar a un tercero para firmar sus llamadas”, y explica qué papel cumple un controlador de borde de sesión (SBC) una vez que usted tiene su certificado.

Por qué STIR/SHAKEN necesita un ecosistema de certificados

Una firma solo tiene valor si quien la comprueba puede confiar en su origen. Cuando un operador de terminación recibe una llamada con un encabezado Identity de STIR/SHAKEN, necesita responder una pregunta de forma rápida y automática: ¿firmó esta llamada un proveedor evaluado por la industria, con un certificado que no ha sido revocado? Responderla a escala, entre miles de proveedores, es exactamente el problema que resuelve una infraestructura de clave pública.

El diseño toma prestado el mismo modelo de confianza que protege a los sitios web. El certificado TLS de un sitio es de confianza porque se encadena hasta una autoridad raíz reconocida en la que su navegador ya confía. STIR/SHAKEN funciona igual, con una diferencia importante: la participación es cerrada y regulada, no abierta. Un certificado no se puede simplemente comprar. Primero hay que confirmar que usted es un proveedor legítimo de servicios de voz, y la capa de gobernanza existe precisamente para hacer cumplir esa condición.

Ese modelo cerrado es lo que hace que el marco resista el abuso. Quien origina robocalls no puede obtener un certificado válido, porque no puede superar la evaluación que produce el token que exige una autoridad de certificación. Es la estructura del ecosistema, más que cualquier pieza de criptografía por sí sola, lo que vincula una firma con una empresa identificable que rinde cuentas.

Los cuatro roles de la cadena de confianza

Cuatro roles distintos hacen funcionar el ecosistema, y tenerlos claros es clave para entender dónde empiezan y dónde terminan sus responsabilidades. Los tres primeros corresponden a la gobernanza y la infraestructura; el cuarto es usted.

Autoridad de gobernanza (STI-GA)

La Secure Telephone Identity Governance Authority, administrada a través de ATIS, está en la cima. No interviene en ninguna llamada. Lo que hace es definir las políticas que siguen todos los demás: las reglas de elegibilidad de los proveedores, los requisitos técnicos de los certificados y el proceso para seleccionar y supervisar al administrador de políticas. La STI-GA también fija el modelo de financiamiento anual que reparte el costo de operar el ecosistema entre los participantes según su tamaño, de modo que los operadores más grandes pagan más y los más pequeños, un mínimo modesto.

Administrador de políticas (STI-PA)

Con el administrador de políticas, la gobernanza se vuelve operativa, y en Estados Unidos ese rol corresponde a iconectiv, seleccionado por la STI-GA y confirmado para un segundo mandato tras el acuerdo inicial. El administrador de políticas hace el trabajo que vuelve real la cadena de confianza: verifica a cada solicitante con base en los registros de la FCC, emite tokens SPC a quienes califican, aprueba y supervisa a las autoridades de certificación, y publica la lista de confianza y los datos de revocación de los que dependen los servicios de verificación. Nada entra al ecosistema sin pasar antes por el administrador de políticas.

Autoridad de certificación (STI-CA)

Una autoridad de certificación aprobada emite el certificado con el que usted firma realmente las llamadas. Iconectiv aprueba cada CA mediante un proceso controlado y la supervisa de forma continua, así que la etiqueta “STI-CA aprobada” tiene un significado real y no es una simple autodeclaración. Una CA no puede emitirle un certificado basándose solo en la confianza o la reputación. Necesita recibir un token SPC válido y vigente, que vincula matemáticamente cada certificado que emite con la evaluación del administrador de políticas.

Proveedor de servicios de voz (usted)

El cuarto rol es el del proveedor que origina o firma las llamadas. Su tarea es registrarse correctamente, obtener un token, conseguir un certificado de una CA aprobada y luego usar ese certificado para firmar las llamadas que envía. La FCC le asigna a usted, como proveedor con la obligación STIR/SHAKEN, la responsabilidad de la firma y de las decisiones sobre el nivel de atestación, incluso cuando el acto mecánico de firmar lo realiza un socio.

Quiénes son las autoridades de certificación aprobadas

El administrador de políticas mantiene la lista oficial de autoridades de certificación aprobadas, y esa lista es la única fuente que debe considerar definitiva al elegir una. Varios proveedores consolidados operan como STI-CA aprobadas, y muchos de ellos incluyen el certificado junto con el resto de la solución de firma, de modo que un proveedor puede obtenerlo todo de un solo socio.

Autoridad de certificación	Oferta típica	Entrega del certificado
TransNexus	Solución completa: CA, firma/verificación, CPS, pruebas	Portal web o API REST
Sansay	Aprobada para certificados de EE. UU. y Canadá	Emisión a través de portal
Otras CA de la lista de aprobadas	Varía según el proveedor (Peeringhub, Telonium, Ribbon y otras)	Portal o API, según el caso

Cómo funciona el registro, paso a paso

Pasar de “operamos una red de voz” a “podemos firmar llamadas con nuestro propio certificado” sigue una secuencia definida. Cada paso depende del anterior, así que el orden importa.

1. Establezca su identidad regulatoriaObtenga un Operating Company Number (OCN) si todavía no tiene uno y presente su Formulario 499-A ante la FCC. Estos registros son los que revisa el administrador de políticas para confirmar que usted es un proveedor legítimo de servicios de voz y no un solicitante anónimo.
2. Regístrese en la Robocall Mitigation DatabasePresente su plan de mitigación de robocalls y certifique su estado de STIR/SHAKEN en la Robocall Mitigation Database de la FCC. Los operadores tienen prohibido aceptar tráfico de proveedores que no figuren en ella, así que este registro es fundamental y debe mantenerse al día.
3. Presente su solicitud al administrador de políticasRegístrese ante iconectiv, que actúa como administrador de políticas. Allí se verifican su OCN, su Formulario 499-A y su inscripción en la RMD, y se confirma que los tres corresponden a la misma entidad legítima antes de otorgarle acceso.
4. Obtenga su token SPCUna vez aprobado, solicite un token SPC al administrador de políticas. El token tiene, por diseño, una vida corta y se renueva periódicamente, por lo que los servicios de firma automatizan su obtención en lugar de tratarlo como una credencial que se consigue una sola vez.
5. Solicite un certificado a una CA aprobadaPresente su token a una autoridad de certificación aprobada. La CA valida el token con el administrador de políticas y luego emite su certificado STI, que entrega a través de su portal web o de su API REST, según el proveedor.
6. Cargue el certificado en su servicio de firmaInstale el certificado y su clave privada donde su servicio de autenticación pueda acceder a ellos. A partir de ese momento, sus llamadas salientes pueden firmarse con su propio certificado y los operadores de terminación pueden verificarlas con la lista de confianza.

La regla de certificado propio de la FCC

Durante años, muchos proveedores pequeños dependieron de un operador upstream o de un tercero para firmar sus llamadas con el certificado de ese tercero. La FCC puso fin a ese esquema. Según la orden Call Authentication Trust Anchor (FCC 24-120), vigente desde el 18 de septiembre de 2025, el proveedor que tiene la obligación STIR/SHAKEN debe garantizar que cada llamada se firme con su propio certificado, obtenido de una autoridad de certificación, y debe tomar sus propias decisiones sobre el nivel de atestación.

La regla no prohíbe por completo la firma a cargo de terceros. Un socio todavía puede realizar el acto mecánico de firmar, pero solo bajo un acuerdo escrito que establezca que las llamadas se firman con el certificado propio del proveedor, que el tercero se limita a la operación de firma y que es el proveedor quien decide el nivel de atestación. Dicho de otro modo, puede delegar la ejecución, pero no la identidad. Usar a un tercero para firmar tráfico sin cumplir estas condiciones constituye una infracción de las normas de autenticación del identificador de llamadas de la Comisión.

La consecuencia práctica es que obtener su propio token SPC y su propio certificado, el proceso descrito más arriba, ya no es opcional para los proveedores que se apoyaban en el certificado de otro. Si usaba el certificado de un operador upstream y desde entonces ha visto bajar la calidad de su atestación, esta regla suele ser la causa, y la solución es completar su propio registro y pasar a firmar con su propio certificado.

Qué papel cumple el SBC una vez que tiene un certificado

El ecosistema de certificados responde a la pregunta de la identidad: quién es usted y si es de confianza. No coloca ninguna firma en una llamada real. Eso ocurre en la ruta de sus llamadas, y ahí es donde el SBC y el servicio de firma hacen su trabajo. Tener claro ese límite mantiene las expectativas en un terreno realista: un SBC no es una autoridad de certificación, ni emite ni custodia la confianza del ecosistema; usa el certificado que usted ya obtuvo.

En una implementación típica, el SBC se ubica en el borde de la red y enruta cada llamada saliente hacia un servicio de firma, el STI-AS, que construye el PASSporT, lo firma con la clave privada de su certificado y devuelve el encabezado Identity que el SBC agrega al INVITE saliente. En las llamadas entrantes, el SBC entrega el encabezado Identity a un servicio de verificación (STI-VS), que comprueba la firma con la lista de confianza y los datos de revocación, y luego aplica su política según el resultado. Como el nivel de atestación es una decisión por llamada, el lugar adecuado para tomarla es el motor de enrutamiento, no una configuración estática.

El servicio de firma y el SBC están separados de la CA precisamente para que pueda elegir cada uno de forma independiente. Un SBC programable se integra con el socio de firma mediante el protocolo que ese socio prefiera, lo que mantiene el ecosistema de certificados, el servicio de firma y el borde de red como tres componentes intercambiables en lugar de un paquete cerrado.

Preguntas frecuentes

Conclusión

El ecosistema de certificados de STIR/SHAKEN es pequeño por diseño: una autoridad de gobernanza que redacta las reglas, un único administrador de políticas que las hace cumplir y emite los tokens, una lista corta de autoridades de certificación aprobadas que emiten los certificados, y los proveedores que se registran y firman. Esa estructura cerrada y verificada es la que permite a un operador de terminación confiar en una firma que nunca antes había visto. Su recorrido por el ecosistema es sencillo una vez que el orden está claro: establezca su identidad regulatoria, regístrese en la Robocall Mitigation Database, pase la evaluación del administrador de políticas, obtenga su token SPC y úselo para conseguir su propio certificado de una CA aprobada.

La regla de certificado propio de la FCC hizo que ese recorrido dejara de ser opcional y pasara a ser obligatorio para los proveedores que dependían del certificado de otro. Una vez que tiene su certificado, el ecosistema ya cumplió su función y la ruta de sus llamadas toma el relevo: el SBC y el servicio de firma usan el certificado para firmar y verificar llamadas en tiempo real.