O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Privilégios de transportadora UICC

O Android 5.1 introduziu um mecanismo para conceder privilégios especiais para APIs relevantes para os proprietários de aplicativos UICC (Universal Integrated Circuit Card). A plataforma Android carrega certificados armazenados em um UICC e concede permissão aos aplicativos assinados por esses certificados para fazer chamadas para várias 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 drasticamente o número de operadoras que podem usar as APIs. Para 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 do operador de rede móvel (MNO) hospedado em canais genéricos de distribuição de aplicativos (como o Google Play), mantendo privilégios especiais nos dispositivos e sem a necessidade para assinar aplicativos com o certificado da plataforma por dispositivo ou pré-instalar como um aplicativo do sistema.

Regras sobre UICC

O armazenamento no UICC é compatível com a especificação GlobalPlatform Secure Element Access Control . O identificador de 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 over-the-air do cartão (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 marca 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 sequência completa do nome do pacote definida no manifesto, codificado em ASCII, com comprimento máximo de 127 bytes.
  • AR-DO ( E3 ) foi estendido para incluir o PERM-AR-DO ( DB ), que é uma máscara de 8 bytes que representa 64 permissões separadas.

Se o PKG-REF-DO não estiver presente, qualquer aplicativo assinado pelo certificado terá acesso concedido; caso contrário, o certificado e o nome do pacote precisam corresponder.

Exemplo de regra

O nome do aplicativo é com.google.android.apps.myapp e o certificado SHA-1 na cadeia 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 na sequência hexadecimal é:

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

Suporte ao arquivo de regras de acesso (ARF)

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

Exemplo de conteúdo ACRF na cadeia 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 aplicativos assinados por este certificado têm privilégios de operadora.

APIs ativadas

O Android suporta as seguintes APIs.

TelephonyManager

SmsManager

Método para permitir que o chamador crie novas mensagens SMS recebidas: injectSmsPdu .

CarrierConfigManager

O método para notificar a configuração foi alterado: notifyConfigChangedForSubId . Para obter instruções, consulte Configuração da operadora .

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 seu arquivo de manifesto com a permissão android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE e inclua um filtro de intenção com a ação #SERVICE_INTERFACE . Os métodos incluem:

Fornecedor 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 API de telefonia em developer.android.com.

Plataforma Android

Em um UICC detectado, a plataforma constrói objetos UICC internos que incluem regras de privilégios de operadora como parte do UICC. UiccCarrierPrivilegeRules.java carrega regras, as analisa da placa UICC e as armazena em cache na memória. Quando uma verificação de privilégio é necessária, UiccCarrierPrivilegeRules compara o certificado de chamada 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

O Compatibility Test Suite (CTS) inclui testes para APIs da operadora em CtsCarrierApiTestCases.apk . Como esse recurso depende dos certificados no UICC, você deve preparar o UICC para passar nesses testes.

Preparando o UICC

Por padrão, CtsCarrierApiTestCases.apk é assinado pela chave de desenvolvedor do Android, com valor de hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Os testes também imprimem o hash de certificado esperado se os certificados com incompatibilidade UICC.

Exemplo de saída:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Para validar a implementação por meio do CTS usando CtsCarrierApiTestCases.apk , você deve ter um UICC de desenvolvedor com as regras UICC corretas ou o suporte a ARF. Você pode solicitar ao fornecedor do cartão SIM de sua escolha que prepare 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 requer serviço de celular ativo para passar nos testes CTS.

Executando testes

Por conveniência, o CTS suporta um token de dispositivo que restringe os testes a serem executados apenas em dispositivos configurados com o mesmo token. Os testes CTS da API de operadora suportam o token do dispositivo sim-card-with-certs . Por exemplo, o seguinte token de dispositivo restringe os testes da API da operadora a serem executados 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, o teste é 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: É bom ter outras regras de segurança no UICC sob o mesmo AID; a plataforma os filtra automaticamente.

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

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 no UICC?

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

Existe 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.

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

R: Consulte a seção "Compatibilidade comportamental da API" do CDD (Android Compatibility Definition Document) . Temos alguns testes de 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 de alguma forma interage ou se sobrepõe a outras tecnologias de acesso SE, por exemplo, SEEK?

R: Como exemplo, o SEEK usa o mesmo AID que no UICC. Portanto, as regras coexistem e são filtradas por SEEK ou UiccCarrierPrivileges .

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

A: Após o estado do SIM carregar a transmissão.

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 mais fino da granularidade no futuro.

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

R: Consulte a entrada SPN no TelephonyManager

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 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 do SMS.

A extensão do 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), 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 alteração no GP, pois isso pode ser incompatível com o ARA-M / ARF existente?

R: Para fornecer segurança à prova de futuro, esta extensão apresenta 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 a todos os aplicativos de dispositivo não cobertos por uma regra específica?

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

De acordo com suas especificações, o PKG-REF-DO usado por si só, sem DeviceAppID-REF-DO , não deve ser aceito. Mas ainda é descrito na Tabela 6-4 como estendendo a 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 .

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

R: Isso é reservado para o futuro e agradecemos sugestões.

Você pode definir mais especificamente o DeviceAppID para Android? Esse é o valor de hash SHA-1 (20 bytes) do certificado do Publisher usado para assinar o aplicativo fornecido. Portanto, o nome não deve refletir esse objetivo? (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 do DeviceAppID são suportados pela especificação existente. Tentamos minimizar as alterações nas especificações para reduzir a barreira à adoção. Para detalhes, consulte Regras sobre UICC .