Privilégios da operadora do UICC

O Android 5.1 introduziu um mecanismo para conceder privilégios especiais a APIs relevantes para os proprietários de apps de cartão de circuito integrado universal (UICC). A plataforma Android carrega certificados armazenados em um UICC e concede permissão a apps assinados por esses certificados para fazer chamadas a algumas APIs especiais.

O Android 7.0 estendeu esse recurso para oferecer suporte a outras fontes de armazenamento para regras de privilégio da operadora UICC, aumentando muito o número de operadoras que podem usar as APIs. Para uma referência de API, consulte CarrierConfigManager. Para instruções, consulte Configuração da operadora.

As operadoras têm controle total do UICC. Assim, esse mecanismo oferece uma maneira segura e flexível de gerenciar apps da operadora de rede móvel (ORM) hospedados em canais genéricos de distribuição de apps (como o Google Play), mantendo privilégios especiais em dispositivos e sem a necessidade de assinar apps com o certificado de plataforma por dispositivo ou pré-instalar como um app do sistema.

Regras sobre UICC

O armazenamento na UICC é compatível com a especificação de controle de acesso ao elemento de segurança GlobalPlatform. O identificador do app (AID) no cartão é A00000015141434C00, e o comando padrão GET DATA é usado para buscar regras armazenadas no cartão. É possível atualizar essas regras com atualizações over the air (OTA) do cartão.

Hierarquia de dados

As regras da UICC usam a seguinte hierarquia de dados (a combinação de letras e números de dois caracteres entre parênteses é a tag do objeto). Cada regra é REF-AR-DO (E2) e consiste em uma concatenação de REF-DO e AR-DO:

  • REF-DO (E1) contém DeviceAppID-REF-DO ou uma concatenação de DeviceAppID-REF-DO e PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) armazena a assinatura SHA-1 (20 bytes) ou SHA-256 (32 bytes) do certificado.
    • PKG-REF-DO (CA) é a string do nome completo do pacote definida no manifesto, codificada em ASCII, com comprimento máximo de 127 bytes.
  • AR-DO (E3) é estendido para incluir PERM-AR-DO (DB), que é uma máscara de bits de 8 bytes que representa 64 permissões separadas.

Se PKG-REF-DO não estiver presente, qualquer app assinado pelo certificado receberá acesso. Caso contrário, o certificado e o nome do pacote precisam corresponder.

Exemplo de regra

O nome do app é com.google.android.apps.myapp e o certificado SHA-1 na string hexadecimal é:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

A regra no UICC em string hexadecimal é:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Compatibilidade com arquivos de regras de acesso

O Android 7.0 adiciona suporte para leitura de regras de privilégio da operadora no arquivo de regras de acesso (ARF).

A plataforma Android primeiro tenta selecionar o AID A00000015141434C00 do aplicativo de regra de acesso (ARA, na sigla em inglês). Se não encontrar o AID no UICC, ele vai recorrer ao ARF selecionando o AID PKCS15 A000000063504B43532D3135. Em seguida, o Android lê o arquivo de regras de controle de acesso (ACRF) em 0x4300 e procura entradas com AID FFFFFFFFFFFF. As entradas com AIDs diferentes são ignoradas, então regras para outros casos de uso podem coexistir.

Exemplo de conteúdo da ACRF em uma string hexadecimal:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Exemplo de conteúdo do arquivo de condições de controle de acesso (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

No exemplo acima, 0x4310 é o endereço do ACCF, que contém o hash do certificado 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Os apps assinados por esse certificado recebem privilégios de operadora.

APIs ativadas

O Android é compatível com as seguintes APIs.

TelephonyManager

TelephonyCallback

TelephonyCallback tem interfaces com um método de callback para notificar o app de chamada quando os estados registrados mudam:

SubscriptionManager

SmsManager

CarrierConfigManager

Para instruções, consulte Configuração da operadora.

BugreportManager

Método para iniciar um relatório de bug de conectividade, que é uma versão especializada do relatório de bug que inclui apenas informações para depurar problemas relacionados à conectividade: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Método para mudar para (ativar) a assinatura especificada: switchToSubscription

CarrierMessagingService

Serviço que recebe chamadas do sistema quando novos SMS e MMS são enviados ou recebidos. Para estender essa classe, declare o serviço no arquivo de manifesto com a permissão android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE e inclua um filtro de intent com a ação #SERVICE_INTERFACE. Os métodos incluem:

  • Método para filtrar mensagens SMS recebidas: onFilterSms
  • Método para interceptar mensagens SMS de texto enviadas do dispositivo: onSendTextSms
  • Método para interceptar mensagens SMS binárias enviadas do dispositivo: onSendDataSms
  • Método para interceptar mensagens SMS longas enviadas do dispositivo: onSendMultipartTextSms
  • Método para interceptar mensagens MMS enviadas do dispositivo: onSendMms
  • Método para fazer o download de mensagens MMS recebidas: onDownloadMms

CarrierService

Serviço que expõe funcionalidades específicas da operadora ao sistema. Para estender essa classe, declare o serviço no arquivo de manifesto do app com a permissão android.Manifest.permission#BIND_CARRIER_SERVICES e inclua um filtro de intent com a ação CARRIER_SERVICE_INTERFACE. Se o serviço tiver uma vinculação de longa duração, defina android.service.carrier.LONG_LIVED_BINDING como true nos metadados do serviço.

A plataforma vincula CarrierService com flags especiais para permitir que o processo de serviço da operadora seja executado em um bucket de espera do app especial. Isso isenta o app de serviços da operadora da restrição de inatividade do app e aumenta a probabilidade de ele permanecer ativo quando a memória do dispositivo está baixa. No entanto, se o app de serviço da operadora falhar por qualquer motivo, ele perderá todos os privilégios acima até que o app seja reiniciado e a vinculação seja restabelecida. Por isso, é fundamental manter a estabilidade do app Carrier Services.

Os métodos em CarrierService incluem:

  • Para substituir e definir as configurações específicas da operadora: onLoadConfig
  • Para informar ao sistema sobre uma mudança intencional de rede da operadora pelo app da operadora: notifyCarrierNetworkChange

Provedor de telefonia

APIs de provedor de conteúdo para permitir modificações (inserir, excluir, atualizar, consultar) no banco de dados de telefonia. Os campos de valores são definidos em Telephony.Carriers. Para mais detalhes, consulte a referência da classe Telephony.

WifiNetworkSuggestion

Ao criar um objeto WifiNetworkSuggestion, use os seguintes métodos para definir um ID de assinatura ou um grupo de assinaturas:

Plataforma Android

Em um UICC detectado, a plataforma cria objetos internos que incluem regras de privilégio da operadora como parte do UICC. O UiccCarrierPrivilegeRules.java carrega as regras, as analisa do cartão UICC e as armazena em cache na memória. Quando uma verificação de privilégio é necessária, UiccCarrierPrivilegeRules compara o certificado do chamador com as próprias regras, uma por uma. Se o UICC for removido, as regras serão destruídas junto com o objeto UICC.

Validação

Para validar a implementação com o Compatibility Test Suite (CTS) usando CtsCarrierApiTestCases.apk, é necessário ter um UICC de desenvolvedor com as regras de UICC ou suporte a ARF corretos. Peça ao fornecedor de chip da sua escolha para preparar um UICC de desenvolvedor com o ARF correto, conforme descrito nesta seção, e use esse UICC para executar os testes. A UICC não exige um serviço de celular ativo para passar nos testes do CTS.

Preparar o UICC

No Android 11 e versões anteriores, CtsCarrierApiTestCases.apk é assinado por aosp-testkey, com valor de hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.

A partir do Android 12, CtsCarrierApiTestCases.apk é assinado por cts-uicc-2021-testkey, valor de hash CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0.

Para executar os testes da API da operadora do CTS no Android 12, o dispositivo precisa usar um SIM com privilégios de operadora do CTS que atendam aos requisitos especificados na versão mais recente da especificação de perfil de teste GSMA TS.48 de terceiros.

O mesmo chip também pode ser usado em versões anteriores ao Android 12.

Modificar o perfil de chip do CTS

  1. Adicionar:privilégios de operadora do CTS no mestre de app de regra de acesso (ARA-M) ou ARF. As duas assinaturas precisam ser codificadas nas regras de privilégio da operadora:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. Criar:arquivos elementares (EFs, na sigla em inglês) USIM do ADF não presentes no TS.48 e necessários para o CTS:
    1. EF_MBDN (6FC7), tamanho do registro: 28, número do registro: 4 
      • Conteúdo
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), tamanho do registro:13, número do registro: 1 
      • Conteúdo: 00FF…FF
        1. EF_MBI (6FC9), tamanho do registro: 4, número do registro: 1
      • Conteúdo: Rec1: 01010101
        1. EF_MWIS (6FCA), tamanho do registro: 5, número do registro: 1
      • Content: 0000000000
  3. Modificação:tabela de serviços USIM: ative os serviços nº 47 e nº 48.
    1. EF_UST (6F38)
      • Conteúdo: 9EFFBF1DFFFE0083410310010400406E01
  4. Modificação:arquivos DF-5GS e DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Conteúdo: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Conteúdo: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Conteúdo: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Conteúdo: A0020000FF…FF
  5. Modificar:use a string de nome da operadora Android CTS nos EFs respectivos que contêm esta designação:
    1. EF_SPN (USIM/6F46)
      • Conteúdo: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Conteúdo: Rec1 430B83413759FE4E934143EA14FF..FF

Corresponder à estrutura do perfil de teste

Faça o download e combine a versão mais recente das seguintes estruturas de perfil de teste genérico. Esses perfis não terão a regra de privilégio da operadora do CTS personalizada nem outras modificações listadas acima.

Executar testes

Para facilitar, o CTS oferece suporte a um token de dispositivo que restringe a execução de testes apenas em dispositivos configurados com o mesmo token. Os testes do CTS da API Carrier são compatíveis com o token do dispositivo sim-card-with-certs. Por exemplo, o token de dispositivo a seguir restringe a execução de testes da API da operadora apenas no dispositivo abcd1234:

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

Quando um teste é executado sem um token de dispositivo, ele é executado em todos os dispositivos.

Perguntas frequentes

Como os certificados podem ser atualizados no UICC?

R: Use o mecanismo de atualização OTA do cartão atual.

A UICC pode coexistir com outras regras?

R: Não há problema em ter outras regras de segurança na UICC com o mesmo AID. A plataforma as filtra automaticamente.

O que acontece quando o UICC é removido de um app que depende dos certificados nele?

R: O app perde os privilégios porque as regras associadas ao UICC são destruídas quando ele é removido.

Existe um limite para o número de certificados no UICC?

R: A plataforma não limita o número de certificados, mas como a verificação é linear, muitas regras podem causar uma latência.

Há um limite para o número de APIs que podemos oferecer suporte com esse método?

R: Não, mas limitamos o escopo às APIs relacionadas à operadora.

Há APIs proibidas de usar esse método? Se sim, como você as aplica? Ou seja, você tem testes para validar quais APIs são compatíveis com esse método?

R: Consulte a seção Compatibilidade comportamental da API do Documento de definição de compatibilidade do Android (CDD). Temos alguns testes do CTS para garantir que o modelo de permissão das APIs não seja alterado.

Como isso funciona com o recurso de vários SIMs?

R: O SIM padrão especificado pelo usuário é usado.

Isso interage ou se sobrepõe de alguma forma a outras tecnologias de acesso a SE, por exemplo, o SEEK?

R: Por exemplo, o SEEK usa o mesmo AID da UICC. Assim, as regras coexistem e são filtradas por SEEK ou UiccCarrierPrivileges.

Quando é um bom momento para verificar os privilégios da operadora?

R: Depois da transmissão do estado do chip carregado.

Os OEMs podem desativar parte das APIs da operadora?

R: Não. Acreditamos que as APIs atuais são o conjunto mínimo, e planejamos usar a máscara de bits para um controle de granularidade mais refinado no futuro.

setOperatorBrandOverride substitui TODAS as outras formas de strings de nome do operador? Por exemplo, SE13, UICC SPN ou NITZ baseado em rede?

Sim, a substituição de marca do operador tem a maior prioridade. Quando definido, ele substitui TODAS as outras formas de strings de nome do operador.

O que a chamada do método injectSmsPdu faz?

R: Esse método facilita o backup/restauração de SMS na nuvem. A chamada injectSmsPdu ativa a função de restauração.

Para a filtragem de SMS, a chamada onFilterSms é baseada na filtragem de porta UDH de SMS? Ou os apps das operadoras têm acesso a TODOS os SMS recebidos?

R: As operadoras têm acesso a todos os dados de SMS.

A extensão de DeviceAppID-REF-DO para oferecer suporte a 32 bytes parece ser incompatível com a especificação atual do GP (que permite apenas 0 ou 20 bytes). Por que você está introduzindo essa mudança? O SHA-1 não é suficiente para evitar colisões? Você já propôs essa mudança ao GP, já que ela pode ser incompatível com versões anteriores do ARA-M/ARF?

R: Para oferecer segurança à prova de futuro, essa extensão introduz o SHA-256 para DeviceAppID-REF-DO, além do SHA-1, que atualmente é a única opção no padrão SEAC do GP. Recomendamos usar o SHA-256.

Se DeviceAppID for 0 (vazio), você vai aplicar a regra a todos os apps do dispositivo que não estão cobertos por uma regra específica?

R: As APIs de operadora exigem que DeviceAppID-REF-DO seja preenchido. Estar vazio é destinado a fins de teste e não é recomendado para implantações operacionais.

De acordo com sua especificação, PKG-REF-DO usado sozinho, sem DeviceAppID-REF-DO, não deve ser aceito. No entanto, ela ainda é descrita na Tabela 6-4 da especificação como uma extensão da definição de REF-DO. Isso é proposital? Como o código se comporta quando apenas PKG-REF-DO é usado em REF-DO?

R: A opção de ter PKG-REF-DO como um item de valor único em REF-DO foi removida na versão mais recente. PKG-REF-DO só pode ocorrer em combinação com DeviceAppID-REF-DO.

Presumimos que podemos conceder acesso a todas as permissões baseadas em operadora ou ter um controle mais refinado. Se sim, o que define o mapeamento entre a máscara de bits e as permissões reais? Uma permissão por turma? Uma permissão por método? 64 permissões separadas são suficientes a longo prazo?

R: Isso está reservado para o futuro, e aceitamos sugestões.

Você pode definir melhor DeviceAppID para Android especificamente? Esse é o valor de hash SHA-1 (20 bytes) do certificado do editor usado para assinar o app. Portanto, o nome não deveria refletir essa finalidade? O nome pode confundir muitos leitores, já que a regra se aplica a todos os apps assinados com o mesmo certificado do editor.

R: O DeviceAppID que armazena certificados é compatível com a especificação atual. Tentamos minimizar as mudanças na especificação para reduzir a barreira à adoção. Para mais detalhes, consulte Regras no UICC.