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 a 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 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 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 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 as 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 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émDeviceAppID-REF-DO
ou uma concatenação deDeviceAppID-REF-DO
ePKG-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 do nome completo do pacote definido 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 bits de 8 bytes representando 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 corresponder.
Exemplo de regra
O nome do aplicativo é com.google.android.apps.myapp
e o certificado SHA-1 na 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
Aceder ao suporte do ficheiro de regras
O Android 7.0 adiciona suporte para ler as regras de privilégio da operadora do arquivo de regra 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
. Aplicativos assinados por este certificado recebem privilégios de operadora.
APIs habilitadas
O Android suporta as seguintes APIs.
Gerenciador de Telefonia
- Método para permitir que o aplicativo da operadora solicite um desafio/resposta ao UICC:
getIccAuthentication
. - Método para verificar se o aplicativo de chamada recebeu privilégios de operadora:
hasCarrierPrivileges
. - Métodos para substituir marca e número:
- Métodos para comunicação UICC direta:
- Método para definir o modo do dispositivo como global:
setPreferredNetworkTypeToGlobal
. - Métodos para obter as identidades do dispositivo ou da rede:
- Identidade Internacional de Equipamento Móvel (IMEI):
getImei
- Identificador de equipamento móvel (MEID):
getMeid
- Identificador de acesso à rede (NAI):
getNai
- Número de série do SIM:
getSimSerialNumber
- Identidade Internacional de Equipamento Móvel (IMEI):
- Método para obter a configuração da operadora:
getCarrierConfig
- Método para obter o tipo de rede para transmissão de dados:
getDataNetworkType
- Método para obter o tipo de rede para serviço de voz:
getVoiceNetworkType
- Métodos para obter as informações sobre o aplicativo UICC SIM (USIM):
- Número de série do SIM:
getSimSerialNumber
- Informações do cartão:
getUiccCardsInfo
- GID1 (ID de grupo level1):
getGroupIdLevel1
- String do número de telefone para a linha 1:
getLine1Number
- Rede móvel terrestre pública proibida (PLMN):
getForbiddenPlmns
- PLMN inicial equivalente:
getEquivalentHomePlmns
- Número de série do SIM:
- Métodos para obter ou definir o número do correio de voz:
- Método para enviar código discador especial:
sendDialerSpecialCode
- Método para redefinir o modem de rádio:
rebootModem
- Métodos para obter ou definir modos de seleção de rede:
- Método para solicitar uma varredura de rede:
requestNetworkScan
- Métodos para obter ou definir os tipos de rede permitidos/preferenciais:
- Métodos para verificar se os dados móveis ou roaming estão habilitados de acordo com as configurações do usuário:
- Métodos para verificar ou definir a conexão de dados com o motivo:
- Método para obter a lista de números de emergência:
getEmergencyNumberList
- Métodos para controlar as redes oportunistas:
- Métodos para definir ou limpar a solicitação de atualização de intensidade do sinal de celular:
TelephonyCallback
TelephonyCallback
possui interfaces com um método de retorno de chamada para notificar o aplicativo de chamada quando os estados registrados mudam:
- O indicador de mensagem em espera mudou:
onMessageWaitingIndicatorChanged
- O indicador de encaminhamento de chamada mudou:
onCallForwardingIndicatorChanged
- A causa da desconexão da chamada do sistema multimídia IP (IMS) foi alterada:
onImsCallDisconnectCauseChanged
- O estado preciso da conexão de dados foi alterado:
onPreciseDataConnectionStateChanged
- A lista atual de números de emergência foi alterada:
onEmergencyNumberListChanged
- O ID da assinatura de dados ativos mudou:
onActiveDataSubscriptionIdChanged
- A rede da operadora mudou:
onCarrierNetworkChange
- O registro de rede ou uma atualização de área de localização/roteamento/rastreamento falhou:
onRegistrationFailed
- A alteração das informações de restrição:
onBarringInfoChanged
- A configuração atual do canal físico mudou:
onPhysicalChannelConfigChanged
Gerenciador de Assinaturas
- Métodos para obter várias informações de assinatura:
- Método para obter o número de assinaturas ativas:
getActiveSubscriptionInfoCount
- Métodos para gerenciar grupos de assinaturas:
- Métodos para obter ou definir a descrição do plano de relacionamento de cobrança entre uma operadora e um assinante específico:
- Método para substituir temporariamente o plano de relacionamento de cobrança entre uma operadora e um assinante específico para ser considerado não medido:
setSubscriptionOverrideUnmetered
- Método para substituir temporariamente o plano de relacionamento de cobrança entre uma operadora e um assinante específico para ser considerado congestionado:
setSubscriptionOverrideCongested
- Método para verificar se o aplicativo com o contexto fornecido está autorizado a gerenciar a assinatura fornecida de acordo com seus metadados:
canManageSubscription
Gerenciador de SMS
- Método para permitir que o chamador crie novas mensagens SMS recebidas:
injectSmsPdu
. - Método para enviar uma mensagem SMS baseada em texto sem escrever no provedor de SMS:
sendTextMessageWithoutPersisting
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 depurar problemas relacionados à conectividade: startConnectivityBugreport
NetworkStatsManager
- Método para consultar o resumo de uso da rede:
querySummary
- Método para consultar o histórico de uso da rede:
queryDetails
- Métodos para registrar ou cancelar o registro do retorno de chamada de uso da rede:
ImsMmTelManager
- Métodos para registrar ou cancelar o registro de retorno de chamada de registro IMS MmTel:
ImsRcsManager
- Métodos para registrar ou cancelar o registro de retorno de chamada de registro IMS RCS:
- Métodos para obter o estado de registro do IMS ou o tipo de transporte:
ProvisioningManager
- Métodos para registrar e cancelar o registro do retorno de chamada das atualizações de provisionamento de recursos do IMS:
- Métodos relacionados ao status de provisionamento para capacidade IMS MmTel ou RCS:
EuiccManager
Método para alternar para (ativar) a assinatura fornecida: switchToSubscription
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 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:
- Método para filtrar mensagens SMS recebidas:
onFilterSms
- Método para interceptar mensagens de texto SMS 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
CarrierService
Serviço que expõe ao sistema funcionalidades específicas da operadora. 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 intenção 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
com sinalizadores especiais para permitir que o processo do serviço da operadora seja executado em um depósito 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 está 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 o aplicativo de serviço da operadora estável.
Métodos em CarrierService
incluem:
- Para substituir e definir as configurações específicas da operadora:
onLoadConfig
- Para informar o sistema sobre uma futura alteração intencional da 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 de classe Telephony
WifiRedeSugestão
Ao criar um objeto WifiNetworkSuggestion
, use os seguintes métodos para definir um ID de assinatura ou um grupo de assinaturas:
- Método para definir um ID de assinatura:
setSubscriptionId
- Método para definir um grupo de assinaturas:
setSubscriptionGroup
plataforma Android
Em um UICC detectado, a plataforma constrói objetos UICC internos que incluem regras de privilégio de transportadora como parte do UICC. UiccCarrierPrivilegeRules.java
carrega regras, analisa-as a partir do 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 a uma. Se o UICC for removido, as regras serão destruídas junto com o objeto UICC.
Validação
Para validar a implementação por meio do Compatibility Test Suite (CTS) usando CtsCarrierApiTestCases.apk
, você deve ter um desenvolvedor UICC com as regras corretas de UICC 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 requer serviço de celular ativo para passar nos testes CTS.
Preparar 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 atendam 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
- Acrescentar: Privilégios de operadora CTS no mestre de aplicação de regra de acesso (ARA-M) ou ARF. Ambas as assinaturas devem ser codificadas nas regras de privilégio da operadora:
-
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
-
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
-
- Criar: arquivos elementares ADF USIM (EFs) não presentes em TS.48 e necessários para CTS:
- EF_MBDN (6FC7), tamanho do registro: 28, número do registro: 4
- Contente
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n: FF…FF
- Contente
- EF_EXT6 (6FC8), tamanho do registro: 13, número do registro: 1
- Conteúdo: 00FF…FF
- EF_MBI (6FC9), tamanho do registro: 4, número do registro: 1
- Conteúdo: Rec1: 01010101
- EF_MWIS (6FCA), tamanho do registro: 5, número do registro: 1
- Conteúdo: 0000000000
- Conteúdo: 00FF…FF
- EF_MBDN (6FC7), tamanho do registro: 28, número do registro: 4
- Modificar: Tabela de serviço USIM: Ativar serviços n°47, n°48
- EF_UST (6F38)
- Conteúdo:
9EFFBF1DFFFE0083410310010400406E01
- Conteúdo:
- EF_UST (6F38)
- Modificar: arquivos DF-5GS e DF-SAIP
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Conteúdo:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Conteúdo:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Conteúdo:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Conteúdo:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Conteúdo:
A0020000FF…FF
- Conteúdo:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Conteúdo:
A0020000FF…FF
- Conteúdo:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Modificar: Use a string do nome da operadora Android CTS nos respectivos EFs contendo esta designação:
- EF_SPN (USIM/6F46)
- Conteúdo:
01416E64726F696420435453FF..FF
- Conteúdo:
- EF_PNN (USIM/6FC5)
- Conteúdo:
Rec1 430B83413759FE4E934143EA14FF..FF
- Conteúdo:
- EF_SPN (USIM/6F46)
Correspondendo à estrutura do perfil de teste
Baixe e combine a versão mais recente das seguintes estruturas de 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 a execução de testes apenas em dispositivos configurados com o mesmo token. Os testes CTS da API da operadora suportam o sim-card-with-certs
do token do dispositivo. Por exemplo, o token de dispositivo a seguir restringe os testes de API da operadora para 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: 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 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 suportar com este método?
R: Não, mas limitamos o escopo às APIs relacionadas à operadora.
Existem algumas APIs proibidas de usar esse método? Em caso afirmativo, como você os aplica? (ou seja, você tem testes para validar quais APIs são suportadas por esse método?)
R: Consulte a seção API Behavioral Compatibility do Android Compatibility Definition Document (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 com outras tecnologias de acesso SE, por exemplo, SEEK?
R: Por exemplo, o SEEK usa o mesmo AID do 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 a transmissão do estado SIM carregado.
Os OEMs podem desabilitar 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 de granularidade mais fino 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 do operador tem a prioridade mais alta. Quando definido, substitui TODAS as outras formas de strings de nome de operador.
O que a chamada do método injectSmsPdu
faz?
R: Este método facilita o backup/restauração do 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 do SMS.
A extensão de 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 alteração para GP, pois isso pode ser incompatível com versões anteriores do ARA-M/ARF existente?
R: 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 GP SEAC. É altamente recomendável usar 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 DeviceAppID-REF-DO
seja preenchido. Estar vazio destina-se a fins de teste e não é recomendado para implantações operacionais.
De acordo com sua especificação, PKG-REF-DO
usado sozinho, sem DeviceAppID-REF-DO
, não deve ser aceito. Mas ainda é 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 em 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 na 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 classe? Uma permissão por método? 64 permissões separadas são suficientes a longo prazo?
R: Isso é reservado para o futuro e aceitamos sugestões.
Você pode definir DeviceAppID
para Android especificamente? Este é o valor de hash SHA-1 (20 bytes) do certificado do Editor usado para assinar o aplicativo fornecido. Portanto, o nome não deveria refletir essa finalidade? (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 pela especificação existente. Tentamos minimizar as alterações nas especificações para diminuir a barreira para adoção. Para obter detalhes, consulte Regras sobre UICC .