Autoridade Certificadora STIR/SHAKEN: como funciona o ecossistema STI-CA

Toda chamada assinada com STIR/SHAKEN carrega uma assinatura criptográfica, e essa assinatura só merece confiança porque remonta a um certificado que a operadora de terminação consegue verificar. Por trás desse certificado existe uma infraestrutura de chaves públicas (PKI) pequena e rigidamente governada: uma autoridade de governança que define as regras, um único Administrador de Políticas que as aplica e uma lista curta de Autoridades Certificadoras aprovadas, que são quem de fato emite os certificados. Se você opera uma rede de voz nos Estados Unidos, não pode assinar nenhuma chamada, em nenhum nível de atestação, até se registrar nesse ecossistema e obter seu próprio certificado.

Este guia explica quem são os participantes, como a cadeia de confiança se encaixa e quais são as etapas exatas que um provedor de serviços de voz segue para se registrar, obter um token SPC (Service Provider Code) e receber um certificado STI. Também trata da regra da FCC sobre certificado próprio, que mudou o que pode significar “usar um terceiro para assinar suas chamadas”, e do papel de um Controlador de Borda de Sessão (SBC) depois que você tem o certificado em mãos.

Por que o STIR/SHAKEN precisa de um ecossistema de certificados

Uma assinatura só tem valor se quem a confere pode confiar na sua origem. Quando uma operadora de terminação recebe uma chamada com o cabeçalho Identity do STIR/SHAKEN, ela precisa responder a uma pergunta de forma rápida e automática: esta chamada foi assinada por um provedor avaliado pelo setor, com um certificado que não foi revogado? Responder a isso em escala, para milhares de provedores, é exatamente o problema que uma infraestrutura de chaves públicas resolve.

A arquitetura reaproveita o mesmo modelo de confiança que protege os sites. O certificado TLS de um site é confiável porque remonta a uma autoridade raiz reconhecida, na qual o seu navegador já confia. O STIR/SHAKEN funciona da mesma forma, com uma diferença importante: a participação é fechada e governada, e não aberta. Não dá para simplesmente comprar um certificado. Primeiro é preciso ser confirmado como provedor legítimo de serviços de voz, e é para garantir isso que a camada de governança existe.

É esse modelo fechado que protege o STIR/SHAKEN contra abusos. Quem faz robocalls não consegue obter um certificado válido porque não passa pela avaliação que gera o token exigido pela Autoridade Certificadora. É a estrutura do ecossistema, e não um elemento criptográfico isolado, que vincula cada assinatura a uma empresa identificável e responsável.

Os quatro papéis da cadeia de confiança

Quatro papéis distintos fazem o ecossistema funcionar, e não confundi-los é a chave para entender onde começam e onde terminam as suas responsabilidades. Os três primeiros são de governança e infraestrutura; o quarto é você.

Autoridade de Governança (STI-GA)

A Secure Telephone Identity Governance Authority, administrada por meio da ATIS, fica no topo. Ela não toca em nenhuma chamada. O que ela faz é definir as políticas que todos os demais seguem: as regras de elegibilidade dos provedores, os requisitos técnicos dos certificados e o processo de seleção e supervisão do Administrador de Políticas. A STI-GA também define o modelo de financiamento anual, que distribui entre os participantes o custo de manter o ecossistema de acordo com o porte de cada um: as maiores operadoras pagam mais, e as menores, um valor mínimo modesto.

Administrador de Políticas (STI-PA)

É no Administrador de Políticas que a governança se torna operacional, e nos Estados Unidos esse papel pertence à iconectiv, escolhida pela STI-GA e confirmada para um segundo mandato após o contrato inicial. O Administrador de Políticas faz o trabalho que torna a cadeia de confiança real: avalia cada candidato com base nos registros da FCC, emite tokens SPC para quem se qualifica, aprova e monitora as Autoridades Certificadoras e publica a lista de confiança e os dados de revogação dos quais os serviços de verificação dependem. Nada entra no ecossistema sem passar antes pelo Administrador de Políticas.

Autoridade Certificadora (STI-CA)

Uma Autoridade Certificadora aprovada emite o certificado com o qual você efetivamente assina as chamadas. A iconectiv aprova cada CA por meio de um processo controlado e a monitora continuamente, de modo que o rótulo “STI-CA aprovada” tem significado real, em vez de ser uma autodeclaração. Uma CA não pode emitir um certificado com base apenas em confiança ou reputação. Ela precisa receber um token SPC válido e vigente, o que vincula matematicamente cada certificado que emite à avaliação feita pelo Administrador de Políticas.

Provedor de serviços de voz (você)

O quarto papel é o do provedor que origina ou assina chamadas. Cabe a você se registrar corretamente, obter um token, conseguir um certificado de uma CA aprovada e então usar esse certificado para assinar as chamadas que envia. A FCC atribui a responsabilidade pela assinatura e pelas decisões de nível de atestação a você, o provedor que tem a obrigação STIR/SHAKEN, mesmo quando o ato mecânico de assinar fica a cargo de um parceiro.

Quem são as Autoridades Certificadoras aprovadas

O Administrador de Políticas mantém a lista oficial de Autoridades Certificadoras aprovadas, e essa é a única fonte que você deve considerar definitiva na hora de escolher uma. Vários fornecedores consolidados atuam como STI-CAs aprovadas, e muitos deles oferecem o certificado junto com o restante da pilha de assinatura, para que o provedor obtenha tudo de um único parceiro.

Autoridade Certificadora	Oferta típica	Entrega do certificado
TransNexus	Pilha completa: CA, assinatura/verificação, CPS, testes	Portal web ou API REST
Sansay	Aprovada para certificados dos EUA e do Canadá	Emissão via portal
Outras da lista de aprovadas	Variam conforme o fornecedor (Peeringhub, Telonium, Ribbon e outras)	Portal ou API, conforme o caso

Como funciona o registro, passo a passo

Passar de “operamos uma rede de voz” para “podemos assinar chamadas com nosso próprio certificado” exige seguir uma sequência definida. Cada etapa depende da anterior, por isso a ordem importa.

1. Estabeleça sua identidade regulatóriaObtenha um Operating Company Number, se ainda não tiver um, e envie o Formulário 499-A da FCC. São esses registros que o Administrador de Políticas consulta para confirmar que você é um provedor legítimo de serviços de voz, e não um candidato anônimo.
2. Registre-se na Robocall Mitigation DatabaseApresente seu plano de mitigação de robocalls e certifique seu status STIR/SHAKEN na Robocall Mitigation Database da FCC. As operadoras são proibidas de aceitar tráfego de provedores que não constem dessa base, por isso esse registro é fundamental e precisa ser mantido atualizado.
3. Solicite o cadastro ao Administrador de PolíticasRegistre-se na iconectiv, que atua como Administrador de Políticas. Ela verifica seu OCN, seu Formulário 499-A e seu registro na RMD e confirma que os três apontam para a mesma entidade legítima antes de liberar o acesso.
4. Obtenha seu token SPC (Service Provider Code)Depois da aprovação, solicite um token SPC ao Administrador de Políticas. O token tem curta duração por definição e é renovado periodicamente, e é por isso que os serviços de assinatura automatizam sua obtenção em vez de tratá-lo como uma credencial de uso único.
5. Solicite um certificado a uma CA aprovadaApresente seu token a uma Autoridade Certificadora aprovada. A CA valida o token junto ao Administrador de Políticas e emite seu certificado STI, entregue pelo portal web ou pela API REST, conforme o fornecedor.
6. Carregue o certificado no seu serviço de assinaturaInstale o certificado e a chave privada em um local acessível ao seu serviço de autenticação. A partir daí, suas chamadas de saída podem ser assinadas com o seu próprio certificado, e as operadoras de terminação podem verificá-las com base na lista de confiança.

A regra da FCC sobre certificado próprio

Durante anos, muitos provedores menores dependeram de uma operadora upstream ou de um terceiro para assinar suas chamadas com o certificado desse terceiro. A FCC acabou com esse arranjo. Pela ordem Call Authentication Trust Anchor (FCC 24-120), em vigor desde 18 de setembro de 2025, o provedor que detém a obrigação STIR/SHAKEN deve garantir que toda chamada seja assinada com o seu próprio certificado, obtido de uma Autoridade Certificadora, e deve tomar as suas próprias decisões de nível de atestação.

A regra não proíbe por completo a assinatura por terceiros. Um parceiro ainda pode executar o ato mecânico de assinar, mas apenas sob um acordo por escrito que estabeleça que as chamadas são assinadas com o certificado do próprio provedor, que o terceiro executa somente a operação de assinatura e que a decisão sobre o nível de atestação é do provedor. Em outras palavras, você pode terceirizar o ato de assinar, mas não a identidade. Usar um terceiro para assinar tráfego sem cumprir essas condições viola as regras de autenticação de identificação de chamadas da Comissão.

Na prática, obter o seu próprio token SPC e o seu próprio certificado, pelo processo descrito acima, deixou de ser opcional para os provedores que se apoiavam no certificado de outra empresa. Se você usava o certificado de uma operadora upstream e viu a qualidade da sua atestação cair desde então, muitas vezes é essa regra que explica a queda, e a solução é concluir o seu próprio registro e passar a assinar com o seu próprio certificado.

Onde o SBC entra depois que você tem o certificado

O ecossistema de certificados responde à pergunta da identidade: quem você é e se você é confiável. Ele não coloca a assinatura em nenhuma chamada real. Isso acontece no seu caminho de chamada, e é ali que o SBC e o serviço de assinatura fazem o seu trabalho. Entender esse limite ajuda a manter as expectativas realistas: um SBC não é uma Autoridade Certificadora e não emite nem detém a confiança do ecossistema; ele usa o certificado que você já obteve.

Em uma implantação típica, o SBC fica na borda da rede e encaminha cada chamada de saída para um serviço de assinatura, o STI-AS, que monta o PASSporT, assina com a chave privada do seu certificado e devolve o cabeçalho Identity que o SBC anexa ao INVITE de saída. Nas chamadas de entrada, o SBC entrega o cabeçalho Identity a um serviço de verificação (STI-VS), que confere a assinatura com base na lista de confiança e nos dados de revogação; em seguida, o SBC aplica a sua política conforme o resultado. Como o nível de atestação é uma decisão por chamada, o lugar certo para tomá-la é o motor de roteamento, e não uma configuração estática.

O serviço de assinatura e o SBC são separados da CA justamente para que você possa escolher cada um de forma independente. Um SBC programável se integra ao parceiro de assinatura pelo protocolo que esse parceiro prefere, o que mantém o ecossistema de certificados, o serviço de assinatura e a borda como três componentes intercambiáveis, em vez de um pacote fechado.

Perguntas frequentes

Conclusão

O ecossistema de certificados STIR/SHAKEN é pequeno de propósito: uma Autoridade de Governança que escreve as regras, um Administrador de Políticas que as aplica e emite tokens, uma lista curta de Autoridades Certificadoras aprovadas que emitem certificados e os provedores que se registram e assinam. É essa estrutura fechada e controlada que permite a uma operadora de terminação confiar em uma assinatura que nunca viu antes. O seu caminho por esse ecossistema é simples quando a ordem fica clara: estabeleça sua identidade regulatória, registre-se na Robocall Mitigation Database, passe pela avaliação do Administrador de Políticas, obtenha seu token SPC e use-o para conseguir o seu próprio certificado de uma CA aprovada.

A regra da FCC sobre certificado próprio tornou esse caminho obrigatório, e não mais opcional, para os provedores que dependiam do certificado de outra empresa. Com o certificado em mãos, o trabalho do ecossistema termina e o seu caminho de chamada assume, com o SBC e o serviço de assinatura usando o certificado para assinar e verificar chamadas em tempo real.