A primeira bifurcação: IPAd ou IPAe
Antes de olhar para qualquer mensagem, há uma decisão arquitectónica que define o resto: onde vive o IPA (IoT Profile Assistant). O SGP.32 permite duas variantes físicas, e o dispositivo escolhe uma em tempo de design.
IPAd — IPA no dispositivo
O IPA corre como software do dispositivo: ou dentro do firmware do modem, ou como aplicação no processador anfitrião. Fala com o eUICC através da interface APDU padrão, da mesma forma que qualquer outra aplicação que use o SIM.
O que ganha: controlo. O OEM decide quando o IPA tenta refrescar o perfil, o que faz perante um falha de rede, que eventos emite para a nuvem. Se o seu produto tem um pipeline OTA sério, esta variante é alavancagem real — pode evoluir a lógica do IPA com cada release de firmware sem tocar no eUICC.
O que custa: superfície de ataque e código. O IPA é software com segredos criptográficos; qualquer compromisso do firmware do modem é um compromisso potencial do IPA. E ocupa código — entre 50 e 200 KB consoante a implementação.
IPAe — IPA dentro do eUICC
O IPA corre como applet Java Card dentro do próprio eUICC. O dispositivo vê-o como outra função do SIM e fala com ele por APDU; toda a lógica de download, activação e rollback acontece dentro do chip.
O que ganha: integração quase plug-and-play. O fabricante do eUICC entrega o chip com o IPAe certificado pela GSMA e validado. Não tem de adicionar lógica ao firmware do dispositivo além de expor a ligação IP ao applet. Para dispositivos com orçamento de código apertado, é a opção razoável.
O que custa: flexibilidade. Qualquer comportamento personalizado — retries especiais, instrumentação de telemetria, integração com um event bus próprio — está limitado ao que o applet do fabricante do chip permita.
O elenco completo: seis actores
Três actores externos ao dispositivo, mais cinco componentes dentro do eUICC. Vale a pena saber o que cada um faz antes de olhar para o protocolo.
O que está fora
- IPA (IoT Profile Assistant): o componente que já conhece. No dispositivo (IPAd) ou dentro do eUICC (IPAe). É o cliente na conversa com o eIM.
- eIM (eSIM IoT remote Manager): o servidor que dá ordens ao IPA. Três responsabilidades: configurar o IPA (com quem falar, com que certificados), entregar-lhe pacotes de instruções, e registar o estado que o IPA reporta.
- SM-DP+ (Subscription Manager — Data Preparation): o servidor do operador móvel. Prepara, cifra e assina o perfil que o eUICC vai receber. É o mesmo SM-DP+ do SGP.22, e a certificação GSMA é obrigatória.
- SM-DS (Subscription Manager — Discovery Service, opcional): um servidor de descoberta. Quando o IPA não sabe a que SM-DP+ pedir um perfil, consulta o SM-DS, que devolve a morada. Útil para dispositivos sem bootstrap pré-configurado.
O que está dentro do eUICC
- ECASD (eUICC Controlling Authority Security Domain): a raiz criptográfica do chip. Contém o certificado de identidade do eUICC, assinado pelo fabricante (Kigen, IDEMIA, Thales, etc.) sob a hierarquia GSMA. Todo o resto deriva daqui.
- ISD-R (Issuer Security Domain — Root): o domínio de gestão. Sabe que perfis estão carregados, qual está activo, e executa as ordens do IPA («activa este, desactiva aquele»).
- ISD-P (Issuer Security Domain — Profile): há um por perfil carregado. Cada ISD-P encapsula um perfil completo de operador (IMSI, Ki, configuração de rede) com as suas próprias chaves de cifra.
- Telecom Framework: a fachada que o modem vê. Expõe a interface SIM padrão (PIN, IMSI, autenticação A3/A5) ao firmware do modem, que não precisa de saber que por trás há um eUICC.
- Profile Package Interpreter: analisa o pacote cifrado que o SM-DP+ entrega e desempacota-o num novo ISD-P. É a peça que descodifica o formato TLV de perfil estandardizado pela GSMA.
ESipa: a conversa nova
A interface IPA ↔ eIM chama-se ESipa. É a contribuição protocolar própria do SGP.32 — não existe no SGP.22 — e está desenhada para as peculiaridades do IoT: redes pouco fiáveis, dispositivos atrás de NAT, larguras de banda escassas, latências altas.
Dois bindings: CoAP e HTTPS
O ESipa define dois transportes para as mesmas mensagens lógicas:
- CoAP sobre UDP com DTLS: o binding nativo IoT. Cabeçalhos de poucos bytes, pensado para redes com MTU pequeno e para conservar bateria. Padrão em LPWA (NB-IoT, LTE-M).
- HTTPS sobre TCP com TLS: o binding nativo IT. Mais fácil de depurar, atravessa corporate proxies sem truques, encaixa em infraestruturas de monitorização padrão. Padrão em 4G/5G e em dispositivos com largura de banda folgada.
Os dois bindings transportam os mesmos tipos de mensagem ao nível lógico — o IPA e o eIM não sabem (e não querem saber) que transporte o outro lado está a usar. O modem escolhe em função das capacidades de rede.
Autenticação mútua
TLS ou DTLS, com certificados em ambos os lados. O IPA prova que é uma instância legítima de IPA apresentando o certificado de identidade do eUICC (assinado pelo fabricante do chip sob a cadeia GSMA). O eIM prova que é o eIM com quem o dispositivo foi configurado para falar, apresentando o seu próprio certificado assinado sob a cadeia do operador do eIM.
Qualquer tentativa de um actor que não tenha o certificado correcto cai no handshake. Esse é o coração do modelo de confiança: não há shared secrets nem tokens revogáveis manualmente; é tudo PKI X.509 padrão.
O que viaja pelo cabo: três tipos de mensagem
O ESipa define três tipos de mensagem primários entre eIM e IPA. Vai reconhecê-los em qualquer trace de rede ou log:
EuiccPackageRequest (eIM → IPA)
A mensagem que leva instruções para o eUICC. O payload pode ser uma de três coisas:
- eUICC Configuration Order (eCO): altera o estado de configuração do eUICC sem tocar em perfis individuais — actualizar metadados, registar o eIM autorizado, ajustar políticas globais.
- Profile State Management Order (PSMO): opera sobre um perfil específico. «Activa o perfil 3», «desactiva o perfil 1», «apaga o perfil 5». O verbo de gestão de frota mais comum.
- Profile Download Trigger: arranca um download de perfil a partir de um SM-DP+ específico. Leva a morada do SM-DP+, o código de activação e os parâmetros que o IPA precisa para iniciar a sessão.
IpaEuiccDataRequest (eIM → IPA)
Pergunta «o que tens neste momento?» O IPA responde com um IpaEuiccDataResponse que enumera os perfis carregados, qual está activo, o espaço disponível e as capacidades do eUICC. É o que o eIM usa para sincronizar o seu modelo do estado da frota.
EimAcknowledgements (IPA → eIM)
Recibos assíncronos. Quando o IPA termina de executar um EuiccPackageRequest, responde com um EimAcknowledgement a dizer «ok, executou», ou «falhou, este é o código de erro». O eIM correlaciona-o com o pacote original e actualiza o estado.
Os dois caminhos pelos quais um perfil chega a casa
Quando o eIM emite um Profile Download Trigger, o IPA tem de ir buscar o perfil ao SM-DP+. O SGP.32 define dois caminhos para essa transferência.
Download directo
O IPA abre uma ligação TLS directamente com o SM-DP+ que o eIM lhe indicou, autentica mutuamente (a Common Mutual Authentication definida pela GSMA), pede o perfil, recebe-o cifrado de ponta a ponta para o eUICC, e instala-o. O eIM não participa para além do trigger.
Usado quando o IPA tem conectividade IP normal e o SM-DP+ é alcançável a partir da rede em que o dispositivo está ligado.
Download indirecto
Quando o IPA não consegue alcançar o SM-DP+ directamente — por exemplo, está atrás de um APN privado que só encaminha para servidores corporativos, ou numa rede operadora que não encaminha para hosts públicos arbitrários — o eIM age como proxy. O eIM descarrega o perfil do SM-DP+ pelo seu lado, e entrega-o ao IPA através do canal ESipa que já tinha aberto.
Importante: o perfil continua cifrado de ponta a ponta para o eUICC. O eIM transporta o bloco cifrado mas não tem as chaves para o decifrar. É isso que torna seguro um eIM operado por um terceiro: vê quando os perfis se movem, mas não o que está dentro deles.
Quando a migração falha: o procedimento de rollback
Esta é a característica que transforma o SGP.32 de uma especificação útil em algo em que confiaria com uma frota de 50 000 dispositivos. No SGP.02, uma migração falhada significava que o dispositivo ficava em silêncio e alguém tinha de ir lá fisicamente. No SGP.32, o IPA pode reverter sozinho.
A mecânica: antes de activar um perfil novo, o IPA regista qual era o perfil anteriormente activo e o momento exacto em que foi desactivado. Se passado um período configurável (tipicamente 24 a 72 horas) o eUICC não tiver recebido uma mensagem de «commit» do eIM através da rede do perfil novo, o IPA assume que a migração não funcionou e reactiva o perfil anterior.
Para que isto funcione bem, o eUICC precisa de uma noção sensata do tempo. Se o dispositivo tem GPS ou NTP, resolve por aí; se não, o relógio do eUICC tem de ser populado a partir do modem em cada arranque. A especificação deixa isto ao integrador, mas é a armadilha prática mais comum em pilotos SGP.32.
Quem avaliza por quem: a cadeia de certificados
Quatro raízes criptográficas, organizadas numa hierarquia que a GSMA define no SGP.21:
- GSMA Root CA: a raiz global. Assina a CA de cada fabricante de eUICC e a CA de cada operador de SM-DP+.
- EUM CA (eUICC Manufacturer): uma por fabricante de chip. Assina o certificado de identidade de cada eUICC que sai de fábrica.
- SM-DP+ CA: uma por operador de SM-DP+. Assina o certificado de cada instância operacional de SM-DP+.
- eIM CA: tradicionalmente, a CA própria do operador do eIM. A GSMA está a trabalhar numa lista comum para facilitar a interoperabilidade, mas hoje em dia é a peça menos padronizada.
A revogação é tratada com CRL/OCSP padrão. Se um eUICC fica comprometido (extracção do chip, fuga de chaves), o seu certificado é revogado; a partir daí, nem o eIM nem o SM-DP+ aceitam handshakes a partir dessa identidade.
O que a maioria dos pilotos faz mal
- Restrições de rede. Se o seu APN privado ou IP fixo não encaminha para hosts arbitrários, vai precisar de download indirecto. Confirme isto com o operador do APN antes de começar — habitualmente requer adicionar a gama de IPs do SM-DP+ à lista de permissões.
- Sincronização de relógio. O rollback depende de saber que horas são. Dispositivos sem GPS ou NTP fiável são os que mais sofrem. Resolva com NITZ a partir da rede móvel ou com um campo de timestamp em cada mensagem ESipa.
- Memória do eUICC. Cada perfil ocupa entre 30 e 100 KB dentro do eUICC. Os eUICCs industriais típicos guardam entre 4 e 8 perfis em simultâneo; isso limita a sua estratégia de fallback e de multi-mercado.
- Caminho de actualização do IPA. Se opta por IPAd, o código do IPA viaja com o seu firmware. Planeie o caminho de actualização do próprio IPA com a mesma seriedade com que planeia o da aplicação.
- Testes de roaming. O SM-DP+ pode estar noutro continente. Verifique latência e MTU a partir do país onde o dispositivo vai ser implementado de facto — pilotos às vezes funcionam no escritório mas falham em campo por timeouts.
Perguntas frequentes
Qual é a diferença entre IPAd e IPAe na prática?
O IPAd (IPA no dispositivo) vive no firmware do modem ou da aplicação, por isso o OEM controla-o e pode adicionar lógica de retry personalizada ou instrumentação — ao custo de mais código do lado do dispositivo e de uma superfície de ataque maior. O IPAe (IPA no eUICC) corre como applet Java Card dentro do próprio eUICC: o fabricante do chip mantém-no, há menos código do lado do dispositivo e a integração está próxima de plug-and-play, ao custo de menos personalização. Dispositivo novo com um pipeline OTA sério → IPAd dá-lhe mais alavancagem. Custo de integração como restrição → IPAe.
Tenho de operar o meu próprio eIM?
Não. O eIM pode ser operado in-house pelo OEM, por um integrador, ou contratado como serviço a um MVNO que o ofereça. A propriedade importante é que deixa de estar trancado ao fabricante do eUICC — não que tenha de construir a plataforma. A parte 3 cobre quando cada opção faz sentido.
O que acontece se um download de perfil for interrompido a meio?
O IPA nunca activa um perfil parcial. Se a transferência for cortada, o dispositivo fica no perfil anterior intacto, e o eIM vê esse estado na próxima IpaEuiccDataResponse. O download é tentado de novo quando a conectividade voltar. Isto é muito diferente do SGP.02, onde uma migração a meio podia deixar o dispositivo num estado misto.
O eIM pode ver o perfil em claro?
Não. O perfil é cifrado de ponta a ponta entre o SM-DP+ e o eUICC específico que o vai receber. No fluxo de download indirecto o eIM encaminha o bloco cifrado, mas não tem as chaves para o decifrar. É isso que torna seguro que o eIM seja operado por um terceiro.
O SGP.32 exige LPWA (NB-IoT, LTE-M) ou funciona também em 4G/5G padrão?
Funciona sobre qualquer transportador IP. O ESipa corre sobre CoAP/DTLS (típico de LPWA, optimizado em bytes) ou sobre HTTPS/TLS padrão (típico de 4G/5G e de implementações atrás de um corporate proxy). O modem e o SO do dispositivo escolhem o binding; o resto do protocolo é idêntico.
O que vem na parte 3
A parte 3 é o guia de implementação. As peças a comprar e a quem, o tradeoff entre operar o seu próprio eIM e contratá-lo, multi-mercado com uma única SKU de hardware, gestão de frota em escala sem perder o controlo, o estado real da interoperabilidade entre fornecedores em 2026, e a longa checklist de RFP.
Se chegou aqui à procura do resumo executivo, o briefing curto de 5 minutos continua a ser o ponto de entrada. Se quer recapitular porque é que SGP.32 existe antes de tomar decisões técnicas, volte à parte 1.