Privilégios da operadora do UICC

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

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

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

Regras do UICC

O armazenamento no UICC é compatível com a especificação de controle de acesso de elemento de segurança GlobalPlatform. O identificador do app (AID, na sigla em inglês) 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 as atualizações over the air (OTA) do cartão.

Hierarquia de dados

As regras do UICC usam a seguinte hierarquia de dados (a letra de dois caracteres e combinação de número entre parênteses é a tag de 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 de nome de pacote completa 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 recebe acesso; caso contrário, o certificado e o nome do pacote precisarão são correspondentes.

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 sobre UICC na string hexadecimal é:

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

Suporte a arquivos de regras de acesso

O Android 7.0 adiciona suporte para a leitura de regras de privilégio da operadora do arquivo de regras de acesso (ARF, na sigla em inglês).

Primeiro, a plataforma Android tenta selecionar o aplicativo de regra de acesso (ARA) AID A00000015141434C00. Se ele não encontrar o AID no UICC, ele volta para o ARF selecionando o AID PKCS15 A000000063504B43532D3135: O Android lê arquivo de regras de controle de acesso (ACRF) em 0x4300 e procura entradas com AID FFFFFFFFFFFF. Entradas com AIDs diferentes são ignoradas, as regras para outros casos de uso podem coexistir.

Exemplo de conteúdo ACRF em 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, na sigla em inglês):

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 de certificado 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Aplicativos assinados por este certificado recebem privilégios de operadora.

APIs ativadas

O Android é compatível com as seguintes APIs.

TelephonyManager

Chamada de telefonia

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

SubscriptionManager

SmsManager

CarrierConfigManager

Para instruções, consulte Configuração do provedor de serviços.

BugreportManager

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

Gerenciador de estatísticas de rede

ImsMmTelManager

ImsRcsManager

ProvisioningManager

Gestor Euicc

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 enviadas do dispositivo: onSendTextSms
  • Método para interceptar mensagens SMS binárias enviadas pelo 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 de 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 a true nos metadados do serviço.

A plataforma vincula CarrierService a sinalizações especiais para permitir que o de serviço da operadora é executado em uma bucket do App em espera. Isso isenta o app de serviço da operadora da restrição de inatividade do app e aumenta a probabilidade de ele permanecer ativo quando a memória do dispositivo estiver baixa. No entanto, se o app de serviço da operadora falhar por qualquer motivo, ele perde todos os privilégios acima até que o app seja reiniciado e a vinculação seja restabelecido. Por isso, é fundamental manter o app do serviço da operadora estável.

Os métodos em CarrierService incluem:

  • Para substituir e definir as configurações específicas da operadora: onLoadConfig
  • Para informar o sistema sobre uma mudança intencional futura na rede da operadora, app da operadora: notifyCarrierNetworkChange

Provedor de telefonia

APIs do 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 ou grupo de assinaturas:

Plataforma Android

Em um UICC detectado, a plataforma constrói objetos UICC internos que incluir regras de privilégios da operadora como parte do UICC. UiccCarrierPrivilegeRules.java carrega regras, as analisa do cartão UICC e as armazena em cache na memória. Quando uma verificação de privilégio for necessária, o UiccCarrierPrivilegeRules vai comparar certificado do autor da chamada com regras próprias, 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 pelo conjunto de teste de compatibilidade (CTS, na sigla em inglês) usando CtsCarrierApiTestCases.apk, é necessário ter um UICC de desenvolvedor com as regras corretas do UICC ou suporte ao ARF. Peça ao fornecedor do chip de sua escolha para preparar um UICC do desenvolvedor com o o ARF correto, conforme descrito nesta seção, e usar esse UICC para executar os testes. O O UICC não exige serviço de rede celular ativo para passar em testes de CTS.

Preparar o UICC

Para o Android 11 e versões anteriores, o CtsCarrierApiTestCases.apk é assinado por aosp-testkey, com o 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, o 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 terceiros do perfil de teste GSMA TS.48.

O mesmo chip também pode ser usado para versões anteriores à Android 12

Modificar o perfil de chip CTS

  1. Adicionar: privilégios de operadora do CTS no mestre de app de regra de acesso (ARA-M) ou ARF. Ambas as 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. Criação: arquivos básicos USIM (EFs) do ADF não estão presentes na TS.48 e necessário 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
      • Conteúdo: 0000000000
  3. Modificar: tabela de serviços USIM: ativar serviços n°47, n°48
    1. EF_UST (6F38)
      • Conteúdo: 9EFFBF1DFFFE0083410310010400406E01
  4. Modificar: 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 correspondentes que contêm essa designação:
    1. EF_SPN (USIM/6F46)
      • Conteúdo: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Conteúdo: Rec1 430B83413759FE4E934143EA14FF..FF

Combinar a estrutura do perfil de teste

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

Executar testes

Para sua conveniência, o CTS oferece suporte a um token de dispositivo que restringe a execução de testes apenas em dispositivos configurados com o mesmo token. CTS da API da operadora Os testes oferecem suporte ao token sim-card-with-certs do dispositivo. Por exemplo: o seguinte token de dispositivo restringe a execução de testes de API da operadora apenas no dispositivo abcd1234:

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

Ao executar um teste sem usar um token de dispositivo, ele é executado em todos dispositivos.

Perguntas frequentes

Como os certificados podem ser atualizados no UICC?

A: Usar o mecanismo de atualização OTA do cartão

O UICC pode coexistir com outras regras?

A: É possível ter outras regras de segurança no UICC com o mesmo AID. A plataforma as filtra automaticamente.

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

A: O app perde os privilégios porque as regras associadas ao UICC são destruídas na remoção do UICC.

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

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

Há um limite para o número de APIs que podem ser aceitas com esse método?

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

Algumas APIs estão 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 seção "Compatibilidade comportamental da API" da página "Compatibilidade do Android" Documento de definição de dados (CDD, na sigla em inglês). Temos alguns testes CTS para garantir que o modelo de permissão das APIs não será alterado.

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

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

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

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

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

A: Depois da transmissão de carregamento do estado do chip.

Os OEMs podem desativar parte das APIs da operadora?

A: 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 preciso no futuro.

O setOperatorBrandOverride substitui TODOS os outros tipos de strings de nome de operador? Por exemplo, SE13, UICC SPN ou NITZ com base em rede?

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

O que a chamada de método injectSmsPdu faz?

A: Esse método facilita o backup/restauração de SMS na nuvem. O 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 da operadora têm acesso a TODOS os SMS recebidos?

A: 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 para o GP, já que ela pode ser incompatível com o ARA-M/ARF?

A: Para oferecer segurança futura, 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 GP SEAC. É altamente recomendável usar o SHA-256.

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

R: As APIs de operadoras exigem que DeviceAppID-REF-DO seja preenchido. O estado vazio é destinado a testes e não é recomendado para implantações operacionais.

De acordo com a especificação, PKG-REF-DO usado sozinho, sem DeviceAppID-REF-DO, não deve ser aceito. Mas ainda é descrito na Tabela 6-4 da especificação como uma extensão da definição de REF-DO. É de propósito? Como o código se comporta quando apenas PKG-REF-DO é usado em REF-DO?

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

Presumimos que possamos conceder acesso a todas as permissões baseadas na operadora ou ter um controle mais preciso. Em caso afirmativo, o que define o mapeamento entre a máscara de bit 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?

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

Você pode definir DeviceAppID especificamente para o Android? Este é o valor de hash SHA-1 (20 bytes) do editor certificado usado para assinar o aplicativo em questão. Portanto, o nome não deve refletir isso. propósito? (O nome pode ser confuso para muitos leitores, pois a regra é aplicável a todos os apps assinados com esse mesmo Certificado de Editor.)

A: Os certificados de armazenamento DeviceAppID têm suporte da especificação atual. Tentamos minimizar as mudanças de especificação para reduzir a barreira para adoção. Para mais detalhes, consulte as Regras do UICC.