Android 5.1 introduziu um mecanismo para conceder privilégios especiais para APIs relevantes aos proprietários de aplicações de placa de circuito integrado universal (UICC). A plataforma Android carrega certificados armazenados em uma UICC e concede permissão para que as APIs assinadas por esses certificados façam chamadas para um punhado de APIs especiais.
Android 7.0 ampliou esse recurso para suportar outras fontes de armazenamento para regras de privilégios de UICCcarrier, aumentando drasticamente o número de operadoras que podem usar as APIs. Para uma referência da API, veja CarrierConfigManager; para instruções, veja CarrierConfiguration.
Carriers têm controle total sobre a UICC, de modo que este mecanismo fornece uma forma 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), sem a necessidade de assinar aplicativos com o certificado de plataforma por dispositivo ou pré-instalar como um aplicativo de sistema.
Regras sobre UICC
Armazenamento na UICC é compatível com a especificaçãoGlobalPlatformSecure Element Access Control. O identificador de aplicação (AID) no cartão é A00000015141434C00, e o padrãoGET DATAcommand é usado para buscar as regras armazenadas no cartão. Você pode atualizar essas regras através de atualizações de cartão por via aérea (OTA).
Hierarquia de dados
Regras UICC usam a seguinte hierarquia de dados (a combinação de dois caracteres de letra e número 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émDeviceAppID-REF-DOou uma concatenação deDeviceAppID-REF-DOePKG-REF-DO.-
DeviceAppID-REF-DO(C1) armazena a assinatura do SHA-1 (20 bytes) ou SHA-256 (32 bytes) do certificado. -
PKG-REF-DO(CA) é a cadeia de nomes completa do pacote definida no manifesto, codificado em ASCII, comprimento máximo de 127 bytes.
-
-
AR-DO(E3) é estendido para incluirPERM-AR-DO(DB), que é uma máscara de 8 bytes bit representando 64 permissões separadas.
Se PKG-REF-DO não estiver presente, qualquer aplicativo assinado pelo certificado tem acesso concedido; caso contrário, tanto o certificado como o nome do pacote necessitam de tomatch.
Exemplo de regra
O nome do aplicativo é com.google.android.apps.myapp e o certificadoSHA-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 sobre UICC em string hexadecimal é:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Suporte de arquivo de regra de acesso (ARF)
Android 7.0 adiciona suporte à leitura de regras de privilégio de portadora a partir do arquivo de regra de acesso (ARF).
A plataforma Android tenta primeiro selecionar o identificador de aplicação de regra de acesso (ARA) (AID) A00000015141434C00. Se ele não encontrar o AID no UICC, ele cai de volta ao ARF selecionando PKCS15 AIDA000000063504B43532D3135. O Android então 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 ignoradas, sorules para outros casos de uso podem coexistir.
Examplo conteúdo ACRF em hexadecimal:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Examplo 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 certificado61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Os aplicativos atribuídos por este certificado recebem privilégios de operadora.
APIs habilitadas
Android suporta as seguintes APIs.
TelephonyManager
- Método para permitir que o aplicativo da operadora peça à UICC um desafio/resposta:
getIccAuthentication. - Método para verificar se o aplicativo de chamada recebeu privilégios de operadora:
hasCarrierPrivileges. - Métodos para sobrepor marca e número:
-
setOperatorBrandOverride -
setLine1NumberForDisplay -
setVoiceMailNumber
-
- Métodos para comunicação direta UICC:
-
iccOpenLogicalChannel -
iccCloseLogicalChannel -
iccExchangeSimIO -
iccTransmitApduLogicalChannel -
iccTransmitApduBasicChannel -
sendEnvelopeWithStatus
-
setPreferredNetworkTypeToGlobal.SmsManager
Método para permitir ao chamador criar novas mensagens SMS de entrada: injectSmsPdu.
CarrierConfigManager
Método para notificar a configuração alterada: notifyConfigChangedForSubId. Para instruções, consulteCarrier Configuration.
CarrierMessagingService
Service que recebe chamadas do sistema quando novos SMS e MMS são enviados. 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 intenção com a ação #SERVICE_INTERFACE. Os métodos incluem:
-
onFilterSms -
onSendTextSms -
onSendDataSms -
onSendMultipartTextSms -
onSendMms -
onDownloadMms
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 emTelephony.Carriers; para mais detalhes, consulte a referênciaTelephony API em developer.android.com.
Plataforma Android
Em uma UICC detectada, a plataforma constrói objetos UICC internos que incluem regras de privilégios de portadora como parte da UICC.UiccCarrierPrivilegeRules.javacarrega regras, analisa-as a partir do cartão UICC, e as armazena em cache na memória. Quando uma verificação de privilégios é necessária, UiccCarrierPrivilegeRules compara o certificado de chamada com suas próprias regras, uma a uma. Se a UICC for removida, os términos são destruídos juntamente com o objeto UICC.
Validação
O Conjunto de Testes de Compatibilidade (CTS) inclui os testes para APIs portadoras emCtsCarrierApiTestCases.apk. Como este recurso depende dos certificados da UICC, você deve preparar a UICC para passar nestes testes.
Preparando a UICC
Por padrão, CtsCarrierApiTestCases.apk é assinado pela chave Androiddeveloper, com valor de hash61: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 certificados na UICCmismatch.
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 do CTS usandoCtsCarrierApiTestCases.apk, você deve ter uma UICC do desenvolvedor com as regras corretas da UICC ou suporte a ARF. Você pode pedir ao fornecedor do cartão SIM de sua escolha para preparar uma UICC do desenvolvedor com a ARF correta, conforme descrito nesta seção, e usar essa UICC para executar os testes. A UICC não requer serviço celular ativo para passar nos testes CTS.
Executar testes
Para conveniência, o CTS suporta um token de dispositivo que restringe a execução dos testes somente em dispositivos configurados com o mesmo token. Os testes CTS da API portadora suportam o token do dispositivo sim-card-with-certs. Por exemplo, o seguinte token de dispositivo restringe os testes da API portadora para rodar somente no dispositivoabcd1234:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
>Ao rodar um teste sem usar um token de dispositivo, o teste roda em todos os dispositivos.
FAQ
Como os certificados podem ser atualizados na UICC?
A: Use o mecanismo de atualização de OTA do cartão existente.
Pode a UICC coexistir com outras regras?
A: É bom ter outras regras de segurança na UICC sob o mesmo AID; a plataforma filtra-as automaticamente.
O que acontece quando a UICC é removida para um aplicativo que depende doscertificados nela?
A: A aplicação perde seus privilégios porque as regras associadas com a UICC são destruídas na remoção da UICC.
Existe um limite no número de certificados na UICC?
A: A plataforma não limita o número de certificados; mas como a verificação é linear, muitas regras podem incorrer numa latência para verificação.
Existe um limite para o número de APIs que podemos suportar com este método?
A: Não, mas limitamos o escopo a APIs relacionadas a portadoras.
Existem algumas APIs proibidas de usar este método? Em caso afirmativo, como você as aplica? (ou seja, você tem testes para validar quais APIs são suportadas com este método?)
A: Veja a seção “API Behavioral Compatibility” 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?
A: O SIM padrão especificado pelo usuário é usado.
Faz isso de alguma forma interagir ou se sobrepor a outras tecnologias de acesso do SE, por exemplo, SEEK?
A: Como um exemplo, SEEK usa o mesmo AID que na UICC. Então as regras coexistem e são filtradas por SEEK ou UiccCarrierPrivileges.
Quando é um bom momento para verificar privilégios de portadora?
A: Depois do estado SIM carregado broadcast.
Os OEMs podem desativar parte das APIs da portadora?
A: Não. Nós acreditamos que as APIs atuais são o conjunto mínimo, e planejamos usar a máscara de bit para um controle de granularidade mais fino no futuro.
Faz setOperatorBrandOverride sobrepor TODAS as outras formas de strings de operatorname? Por exemplo, SE13, UICC SPN, ou NITZ baseado em rede?
A: Consulte a entrada SPN emTelephonyManager
O que o método injectSmsPdu chama?
A: Este método facilita o backup/restauração de SMS na nuvem. A chamada injectSmsPdu permite a função de restauração.
Para filtragem de SMS, a chamada onFilterSms é baseada na filtragem da porta UDH doSMS? Ou os aplicativos 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 suportar32 bytes parece ser incompatível com as especificações atuais do GP (que permite apenas 0 ou 20 bytes), então por que você está introduzindo esta alteração? O SHA-1 não é suficiente para evitar colisões? Você já propôs esta alteração para o GP, já que isso poderia ser incompatível com o ARA-M/ARF?
A: Para fornecer segurança à prova de 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 SEAC do GP. Nós recomendamos fortemente o uso do 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?
A: APIs portadoras requerem DeviceAppID-REF-DO ser populadas.Estar vazio é destinado a fins de teste e não é recomendado para implementações operacionais.
De acordo com suas especificações, PKG-REF-DO usado apenas por si só, sem DeviceAppID-REF-DO, não deve ser aceito. Butit’s ainda é descrito na Tabela 6-4 como estendendo a definição deREF-DO. Isto é de propósito? Como o codebehave quando apenas PKG-REF-DO é usado em REF-DO?
A: A opção de ter PKG-REF-DO como um único item de valor em REF-DO foi removida na última versão. PKG-REF-DO só deve ocorrer em combinação com DeviceAppID-REF-DO.
Partimos do princípio de que podemos conceder acesso a todas as permissões baseadas em portadoras ou ter um controle mais fino. 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 permethod de permissão? 64 permissões separadas são suficientes no longo prazo?
A: Isto é reservado para o futuro, e nós agradecemos sugestões.
Pode definir melhor DeviceAppID para Androids especificamente? Este é o valor do hash SHA-1 (20 bytes) do Publishercertificate usado para assinar o aplicativo dado, então o nome não deveria refletir esse propósito? (O nome pode ser confuso para muitos leitores, pois a regra é então aplicável a todos os aplicativos assinados com esse mesmo certificado do Publisher). Nós tentamos minimizar as mudanças de especificações para diminuir a barreira para adoção. Para obter detalhes, consulte Regras sobre UICC.