Google está empenhada em fazer avançar a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Privilégios UICC Portador

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

Android 7.0 estendeu esse recurso para apoiar outras fontes de armazenamento de regras de privilégio transportadora UICC, aumentando dramaticamente o número de portadores que podem usar as APIs. Para uma referência de API, consulte CarrierConfigManager ; Para instruções, consulte Configuração do portador .

Operadoras têm controle total da UICC, de modo que este mecanismo oferece uma maneira segura e flexível para gerenciar aplicativos do operador de rede móvel (MNO) hospedado em canais de distribuição aplicativo genéricos (como o Google Play), mantendo privilégios especiais sobre os dispositivos e sem a necessidade ao sinal de aplicativos com o certificado por dispositivo plataforma ou pré-instalação como um aplicativo do sistema.

Regras sobre UICC

Armazenamento no UICC é compatível com o GlobalPlatform seguros especificação elemento de controle de acesso . O identificador de aplicação (AID) no cartão é A00000015141434C00 , eo padrão GET DATA comando é usado para buscar regras armazenadas no cartão. Você pode atualizar essas regras através de cartão de over-the-air (OTA) atualizações.

A hierarquia de dados

regras UICC usar a hierarquia de dados seguinte (a carta de dois caracteres e combinação de número entre parênteses é a marca de objeto). Cada regra é REF-AR-DO ( E2 ) e consiste de 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 seqüência de nome completo do pacote definido no manifesto, ASCII codificado, comprimento máximo de 127 bytes.
  • AR-DO ( E3 ) é estendido para incluir PERM-AR-DO ( DB ), que é uma máscara de bits de 8 byte representando 64 permissões separadas.

Se PKG-REF-DO não está presente, qualquer app assinado pelo certificado é concedido acesso; caso contrário, o certificado ea necessidade nome do pacote para corresponder.

exemplo regra

O nome do aplicativo é com.google.android.apps.myapp eo 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

arquivo de regra de acesso de suporte (ARF)

Android 7.0 adiciona suporte para a leitura regras de privilégio portadora do arquivo regra de acesso (ARF).

A plataforma Android primeiras tentativas para selecionar o identificador de aplicação (AID) regra de acesso miniaplicativo (ARA) A00000015141434C00 . Se ele não encontrar o AID no UICC, ele volta para ARF seleccionando PKCS15 AID A000000063504B43532D3135 . Android, em seguida, lê o arquivo de regras de controle de acesso (ACRF) em 0x4300 e procura por entradas com AID FFFFFFFFFFFF . Entradas com diferentes AIDs são ignorados, então as regras para outros casos de uso podem co-existir.

conteúdo Exemplo ACRF em cadeia hex:

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

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

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 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 é concedido privilégios transportadora.

APIs ativadas

suportes Android as seguintes APIs.

TelephonyManager

SMSManager

Método para permitir chamadas para criar novas mensagens SMS recebidas: injectSmsPdu .

CarrierConfigManager

Método para notificar configuração foi alterada: notifyConfigChangedForSubId . Para obter instruções, consulte Configuração do portador .

CarrierMessagingService

Serviço que recebe chamadas do sistema quando um novo SMS e MMS são enviados ou recebidos. Para estender esta classe, declare o serviço em seu arquivo de manifesto com a android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE permissão e incluem um filtro de intenções com o #SERVICE_INTERFACE ação. Os métodos incluem:

provedor de telefonia

APIs de provedor de conteúdo para permitir modificações (insert, delete, update, de consulta) para o banco de dados de telefonia. Campos valores estão definidos em Telephony.Carriers ; para mais detalhes, consulte Telephony referência API em developer.android.com.

plataforma Android

Em um UICC detectado, a plataforma constrói objetos UICC internos que incluem regras de privilégio operadora como parte da UICC. UiccCarrierPrivilegeRules.java regras cargas, analisa-as do cartão UICC, e armazena-os na memória. Quando uma verificação de privilégio é necessário, UiccCarrierPrivilegeRules compara o certificado chamador com suas próprias regras, um por um. Se a UICC é removido, as regras são destruídos junto com o objeto UICC.

Validação

A compatibilidade Test Suite (CTS) inclui testes para APIs veiculares em CtsCarrierApiTestCases.apk . Como esse recurso depende de certificados no UICC, você deve preparar o UICC para passar esses testes.

Preparar a UICC

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

Exemplo de saída:

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

A fim de validar a implementação através de CTS usando CtsCarrierApiTestCases.apk , você deve ter um UICC desenvolvedor com as regras UICC corretas ou suporte ARF. Você pode solicitar ao fornecedor do cartão SIM de sua escolha para preparar um UICC desenvolvedor com o ARF direito, conforme descrito nesta seção e uso que UICC para executar os testes. Será que o UICC não exigem serviço de celular ativo para passar por testes de CTS.

execução de testes

Por conveniência, CTS suporta um dispositivo de fichas que restringe os testes para executar apenas em dispositivos configurados com igual modo. Testes transportadora API CTS apoiar o dispositivo de token de sim-card-with-certs . Por exemplo, o seguinte dispositivo de fichas testes API restringe veiculares para executar 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, as execuções de teste em todos os dispositivos.

Perguntas frequentes

Como os certificados podem ser atualizados no UICC?

A: Use o mecanismo de cartão de atualização OTA existente.

Can UICC co-existir com outras regras?

A: É bom ter outras regras de segurança no UICC sob mesma ajuda; a plataforma filtra-los automaticamente.

O que acontece quando a UICC é removido para um aplicativo que conta com os certificados nele?

A: O aplicativo perde seus privilégios porque as regras associadas com a UICC são destruídos na remoção UICC.

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

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

Existe um limite para o número de APIs que pode suportar com este método?

A: Não, mas nós limitar o âmbito de APIs portadora relacionado.

Há algumas APIs proibidas de usar esse método? Se assim for, como você aplicá-las? (isto é, você tem testes para validar que APIs são suportados com este método?)

A: Consulte a seção "Behavioral compatibilidade API" do Documento de Definição de Compatibilidade Android (CDD) . Temos testa alguns CTS para se certificar de que o modelo de permissão das APIs não é alterado.

Como isso funciona com o recurso multi-SIM?

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

Será que isso em qualquer interagem forma ou de sobreposição com outras tecnologias de acesso SE, por exemplo, SEEK?

A: Como um exemplo, SEEK usos do mesmo AUXÍLIO como no UICC. Assim, a co-existir regras e são filtrados por qualquer SEEK ou UiccCarrierPrivileges .

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

A: Depois que o estado de SIM carregado transmissão.

Can OEMs desativar parte de APIs operadora?

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

Does setOperatorBrandOverride substituir todas as outras formas de cordas nome do operador? Por exemplo, SE13, UICC SPN, ou rede baseada em NITZ?

A: Consulte a entrada SPN em TelephonyManager

O que a injectSmsPdu chamada de método fazer?

A: Este método facilita o backup SMS / restore na nuvem. O injectSmsPdu chamada activa a função de restauro.

Para a filtragem de SMS, é o onFilterSms chamada baseado em filtragem de portas SMS UDH? Ou aplicativos transportadora tem acesso a todos os SMS recebidos?

A: Operadoras têm acesso a todos os dados SMS.

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

A: Para proporcionar segurança à prova de futuro, esta extensão introduz SHA-256 para DeviceAppID-REF-DO , além de SHA-1, que é atualmente a única opção no padrão GP SEAC. É altamente recomendável utilizar SHA-256.

Se DeviceAppID é 0 (vazio), você aplicar a regra a todos os dispositivos não os aplicativos coberto por uma regra específica?

A: APIs do portador exigem DeviceAppID-REF-DO ser preenchido. Estar vazio se destina para fins de teste e não é recomendado para implantações operacionais.

De acordo com sua especificação, PKG-REF-DO utilizado apenas por si mesmo, sem DeviceAppID-REF-DO , não deve ser aceite. Mas ele ainda está descrito na Tabela 6-4 como estender a definição de REF-DO . É isso de propósito? Como é que se comportam de código quando apenas PKG-REF-DO é usado em REF-DO ?

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

Nós assumimos que podemos conceder acesso a todas as permissões com base em transportadora ou ter controle mais detalhado. Se assim for, o que define o mapeamento entre a máscara de bits e as permissões reais? Uma permissão por classe? Uma permissão por método? São 64 permissões separadas o suficiente no longo prazo?

A: Este é reservado para o futuro, e congratulamo-nos com sugestões.

Você ainda poderá definir DeviceAppID para Android especificamente? Este é o SHA-1 (20 bytes) valor de hash do certificado Publisher usado para assinar o aplicativo dado, de modo que o nome não deve refletir o efeito? (O nome poderia ser confuso para muitos leitores como a regra é então aplicável a todos os aplicativos assinados com o mesmo certificado Publisher.)

A: Os DeviceAppID armazenamento de certificados é suportado pela especificação existente. Nós tentamos minimizar as alterações de especificação para reduzir a barreira para adoção. Para mais detalhes, consulte Regras sobre UICC .