O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Privilégios de operadora UICC

O Android 5.1 introduziu um mecanismo para conceder privilégios especiais para APIs relevantes para os proprietários de aplicativos de cartão 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 um punhado de 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 uma referência de API, consulte CarrierConfigManager ; Para instruções, consulte Configuração do portador .

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 de distribuição de aplicativos genéricos (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 em 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 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 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 e o nome do pacote precisam ser iguais.

Exemplo de 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 em UICC em string hexadecimal é:

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

Suporte para arquivo de regra de acesso (ARF)

O Android 7.0 adiciona suporte para leitura de regras de privilégio de operadora a partir do arquivo de regras 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 . As entradas com AIDs diferentes são ignoradas, portanto, 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 de 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 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 oferece suporte às 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 novos 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 (inserir, excluir, atualizar, consultar) no 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 de portadora como parte do 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 o UICC for removido, as regras serão destruídas junto com o objeto UICC.

Validação

Para validar a implementação através de Compatibilidade Test Suite (CTS) usando CtsCarrierApiTestCases.apk , você deve ter um UICC desenvolvedor com as regras UICC corretas ou suporte ARF. Você pode pedir 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 usar esse UICC para executar os testes. O UICC não requer serviço de celular ativo para passar nos testes CTS.

Preparando o UICC

Para Android 11 e inferior, CtsCarrierApiTestCases.apk é assinado por aosp-testkey , 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 .

Começando no Android 12, CtsCarrierApiTestCases.apk é assinado pelo cts-uicc-2021-testkey valor 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 transportadora API CTS no Android 12, o dispositivo precisa usar um SIM com privilégios transportadora CTS atender os requisitos especificados na versão mais recente de terceiros GSMA TS.48 teste de perfil de especificação.

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

Modificando o Perfil CTS SIM

  1. Adicionar: Privilégios CTS Carrier em 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. 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
  1. Criar: ADF USIM EFS não presente em TS.48 e necessário 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
  2. Modificar: Tabela Serviço USIM: Ativar serviços n ° 47, n ° 48
    1. EF_UST (6F38)
      • Conteúdo: 9EFFBF1DFFFE0083410310010400406E01
  3. Modificar: DF-5GS e DF-SAIP Arquivos
    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
  4. Modificar: cordas portador nome será CTS Android nos respectivos FE contendo esta designação:
    1. EF_SPN (USIM / 6F46)
      • Conteúdo: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM / 6FC5)
      • Conteúdo: Rec1 430B83413759FE4E934143EA14FF..FF

Combinando a estrutura do perfil de teste

Faça o download e coincidir com a versão mais recente das seguintes estruturas perfil de teste genérico. 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 os testes para serem executados apenas em dispositivos configurados com o mesmo token. 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, 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 incorrer em uma 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 à operadora.

Existem algumas APIs proibidas de usar este método? Em caso afirmativo, como você os aplica? (ou seja, você tem testes para validar quais APIs são compatíveis com este método?)

A: Consulte a seção "Behavioral compatibilidade API" do Documento de Definição de Compatibilidade 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 de alguma forma interage ou se sobrepõe a outras tecnologias de acesso SE, por exemplo, SEEK?

R: Como exemplo, SEEK usa o mesmo AID do UICC. Assim, a co-existir regras e são filtrados por qualquer SEEK ou UiccCarrierPrivileges .

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

R: Depois que o estado do SIM carregou a transmissão.

Os OEMs podem desativar parte das APIs de 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 preciso no futuro.

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

A: Consulte a entrada SPN em TelephonyManager

O que a injectSmsPdu chamada de método fazer?

R: Este método facilita o backup / restauração de SMS 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 os aplicativos da operadora têm acesso a TODOS os SMS recebidos?

R: As 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? O SHA-1 não é suficiente para evitar colisões? Você já propôs essa alteração ao GP, pois isso poderia ser incompatível com o 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 usar 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 a 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 .

Presumimos que podemos conceder acesso a todas as permissões baseadas em operadora ou ter um 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 no longo prazo?

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

Você ainda poderá definir DeviceAppID para Android especificamente? Este é o valor de hash SHA-1 (20 bytes) do certificado do editor usado para assinar o aplicativo fornecido, então 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.)

A: Os DeviceAppID armazenamento de certificados é suportado pela especificação existente. Tentamos minimizar as mudanças nas especificações para diminuir a barreira de adoção. Para mais detalhes, consulte Regras sobre UICC .