Privilégios da operadora UICC

O Android 5.1 introduziu um mecanismo para conceder privilégios especiais para APIs relevantes aos proprietários de aplicativos de placa de circuito integrado universal (UICC). A plataforma Android carrega certificados armazenados em um UICC e concede permissão aos 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 UICC, aumentando drasticamente o número de operadoras que podem usar as APIs. Para obter uma referência de API, consulte CarrierConfigManager ; para obter instruções, consulte Configuração da operadora .

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

Regras do UICC

O armazenamento no UICC é compatível com a especificação GlobalPlatform Secure Element Access Control . O identificador do aplicativo (AID) no cartão é A00000015141434C00 e o comando GET DATA padrão é usado para buscar regras armazenadas no cartão. Você pode atualizar essas regras por meio de atualizações de cartão over-the-air (OTA).

Hierarquia de dados

As regras 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 completa do nome do pacote definida no manifesto, codificada em ASCII, 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 aplicativo assinado pelo certificado terá acesso; caso contrário, o certificado e o nome do pacote precisam ser iguais.

Exemplo de regra

O nome do aplicativo é com.google.android.apps.myapp e o certificado SHA-1 em 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

Suporte a arquivos de regras de acesso

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

A plataforma Android primeiro tenta selecionar o aplicativo de regra de acesso (ARA) AID A00000015141434C00 . Se não encontrar o AID no UICC, ele retornará ao ARF selecionando PKCS15 AID A000000063504B43532D3135 . O Android então lê o arquivo de regras de controle de acesso (ACRF) em 0x4300 e procura entradas com AID FFFFFFFFFFFF . Entradas com AIDs diferentes são ignoradas, portanto 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):

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 para 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 aplicativos assinados por este certificado recebem privilégios de operadora.

APIs habilitadas

O Android oferece suporte às seguintes APIs.

Gerenciador de Telefonia

TelefoniaRetorno de chamada

TelephonyCallback possui interfaces com um método de retorno de chamada para notificar o aplicativo chamador quando os estados registrados mudam:

Gerenciador de assinaturas

Gerenciador de SMS

CarrierConfigManager

  • Método para notificar a configuração alterada: notifyConfigChangedForSubId .
  • Método para obter a configuração da operadora para a assinatura padrão: getConfig
  • Método para obter a configuração da operadora para a assinatura especificada: getConfigForSubId

Para obter 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 depuração de problemas relacionados à conectividade: startConnectivityBugreport

Gerenciador de estatísticas de rede

ImsMmTelManager

ImsRcsManager

Gerente de Provisionamento

EuiccManager

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

Serviço de mensagens da operadora

Serviço que recebe chamadas do sistema quando novos SMS e MMS são enviados ou recebidos. Para estender esta classe, declare o serviço em seu 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 baixar mensagens MMS recebidas: onDownloadMms

Serviço de transportadora

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 aplicativo 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 a sinalizadores especiais para permitir que o processo do serviço da operadora seja executado em um bucket especial de espera do aplicativo . Isso isenta o aplicativo de serviço da operadora da restrição de inatividade do aplicativo e aumenta a probabilidade de ele permanecer ativo quando a memória do dispositivo estiver baixa. No entanto, se o aplicativo de serviço da operadora travar por qualquer motivo, ele perderá todos os privilégios acima até que o aplicativo seja reiniciado e a ligação seja restabelecida. Portanto, é fundamental manter estável o aplicativo de serviço da operadora.

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 na rede da operadora pelo aplicativo 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 obter mais detalhes, consulte a referência da classe Telephony

Sugestão de rede Wi-Fi

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 constrói objetos UICC internos que incluem regras de privilégio de operadora como parte do UICC. UiccCarrierPrivilegeRules.java carrega regras, analisa-as no 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 suas 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 através do Compatibility Test Suite (CTS) usando CtsCarrierApiTestCases.apk , você deve ter um desenvolvedor UICC com as regras UICC corretas ou suporte ARF. Peça ao fornecedor do cartão SIM de 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. O UICC não exige serviço celular ativo para passar nos testes CTS.

Prepare o UICC

Para Android 11 e inferior, 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 testes de API de operadora CTS no Android 12, o dispositivo precisa usar um SIM com privilégios de operadora CTS que atenda aos requisitos especificados na versão mais recente da especificação de perfil de teste GSMA TS.48 de terceiros.

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

Modificando o perfil CTS SIM

  1. Adicionar: privilégios da operadora CTS no mestre de aplicação de regras de acesso (ARA-M) ou ARF. Ambas as assinaturas devem 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. 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) ADF USIM não presentes em TS.48 e necessários para CTS:
    1. EF_MBDN (6FC7), tamanho do registro: 28, número do registro: 4
      • Contente
        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ço USIM: Habilitar 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 respectivos EFs contendo esta designação:
    1. EF_SPN (USIM/6F46)
      • Conteúdo: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Conteúdo: Rec1 430B83413759FE4E934143EA14FF..FF

Correspondendo à estrutura do perfil de teste

Baixe e combine a versão mais recente das seguintes estruturas genéricas de perfil de teste. Esses perfis não terão a regra CTS Carrier Privilege personalizada ou outras modificações listadas acima.

Executando testes

Por 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. Os testes Carrier API CTS suportam o token do dispositivo sim-card-with-certs . Por exemplo, o token de dispositivo a seguir restringe a execução de testes de API da operadora somente no dispositivo abcd1234 :

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

Ao executar um teste sem usar um token de dispositivo, o teste será 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 existente.

O UICC pode coexistir com outras regras?

R: Não há problema em ter outras regras de segurança no UICC sob o mesmo AID; a plataforma os filtra automaticamente.

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

R: O aplicativo perde seus 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 na UICC?

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

Existe um limite para o número de APIs que podemos oferecer suporte com este método?

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

Existem algumas APIs proibidas de usar este método? Se sim, como você os aplica? (ou seja, você tem testes para validar quais APIs são suportadas com este método?)

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

Como isso funciona com o recurso multi-SIM?

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

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

R: Por exemplo, 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?

R: Após a transmissão carregada do estado do SIM.

Os OEMs podem desabilitar parte das APIs das operadoras?

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

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

Sim, a substituição da marca da operadora tem a prioridade mais alta. Quando definido, ele substitui TODAS as outras formas de strings de nomes de operadores.

O que a chamada do método injectSmsPdu faz?

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

Para filtragem de SMS, a chamada onFilterSms é baseada na filtragem de porta SMS UDH? Ou os aplicativos da operadora têm acesso a TODOS os SMS recebidos?

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

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

R: Para fornecer segurança preparada para o futuro, esta 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 SHA-256.

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

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

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

R: A opção de ter PKG-REF-DO como um item de valor único no REF-DO foi removida na versão mais recente. PKG-REF-DO deve ocorrer apenas 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 no longo prazo?

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

Você pode definir ainda mais DeviceAppID para Android especificamente? Este é o valor hash SHA-1 (20 bytes) do certificado do Publicador usado para assinar o aplicativo específico. Portanto, o nome não deveria refletir esse propósito? (O nome pode ser confuso para muitos leitores, pois a regra é aplicável a todos os aplicativos assinados com o mesmo certificado de editor.)

R: Os certificados de armazenamento DeviceAppID são suportados pelas especificações existentes. Tentamos minimizar as alterações nas especificações para diminuir a barreira de adoção. Para obter detalhes, consulte Regras no UICC .