O Android 5.1 introduziu um mecanismo para conceder privilégios especiais para APIs relevantes para os proprietários de apps de cartão de circuito integrado universal (UICC). O A plataforma Android carrega certificados armazenados em um UICC e concede permissão a aplicativos assinados por esses certificados para fazer chamadas para algumas APIs especiais.
O Android 7.0 estendeu esse recurso para oferecer suporte a outras fontes de armazenamento para regras de privilégio de operadora do UICC, aumentando drasticamente o número de operadoras que podem usar as APIs. Para uma referência da API, consulte CarrierConfigManager; para instruções, consulte Operadora Configuração.
As operadoras têm controle total do UICC, então esse mecanismo oferece uma maneira segura e flexível de gerenciar apps do operador de rede móvel (MNO, na sigla em inglês) hospedados em canais de distribuição de apps genéricos (como o Google Play), mantendo privilégios especiais nos dispositivos e sem a necessidade de assinar apps com o certificado de plataforma por dispositivo ou pré-instalar como um app do sistema.
Regras do UICC
O armazenamento no UICC é compatível com a
especificação de controle de acesso de elemento de segurança
GlobalPlatform. O identificador do app
(AID, na sigla em inglês) no cartão é A00000015141434C00
, e o comando
padrão GET DATA
é usado para buscar regras armazenadas no cartão. É possível atualizar essas regras
com as atualizações over the air (OTA) do cartão.
Hierarquia de dados
As regras do UICC usam a seguinte hierarquia de dados (a letra de dois caracteres e
combinação de número entre parênteses é a tag de 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 de nome de pacote completa definida no manifesto, codificada em ASCII, com comprimento máximo de 127 bytes.
AR-DO
(E3
) é estendido para incluirPERM-AR-DO
(DB
), que é uma máscara de bits de 8 bytes que representa 64 permissões separadas.
Se PKG-REF-DO
não estiver presente, qualquer app assinado pelo certificado
recebe acesso; caso contrário, o certificado e o nome do pacote precisarão
são correspondentes.
Exemplo de regra
O nome do app é 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 sobre UICC na string hexadecimal é:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Suporte a arquivos de regras de acesso
O Android 7.0 adiciona suporte para a leitura de regras de privilégio da operadora do arquivo de regras de acesso (ARF, na sigla em inglês).
Primeiro, a plataforma Android tenta selecionar o aplicativo de regra de acesso
(ARA) AID A00000015141434C00
. Se ele não encontrar
o AID no UICC, ele volta para o ARF selecionando o AID PKCS15
A000000063504B43532D3135
: O Android lê
arquivo de regras de controle de acesso (ACRF) em 0x4300
e procura entradas
com AID FFFFFFFFFFFF
. Entradas com AIDs diferentes são ignoradas,
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 do arquivo de condições de controle de acesso (ACCF, na sigla em inglês):
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 de 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 ativadas
O Android é compatível com as seguintes APIs.
TelephonyManager
- Método para permitir que o app da operadora solicite um desafio/resposta ao UICC:
getIccAuthentication
- Método para verificar se o app de chamada recebeu privilégios
da operadora:
hasCarrierPrivileges
. - Métodos para substituir a marca e o número:
- Métodos para comunicação direta do UICC:
- Método para definir o modo do dispositivo como global:
setPreferredNetworkTypeToGlobal
- Métodos para conseguir as identidades do dispositivo ou da rede:
- Identificação 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 chip:
getSimSerialNumber
- Identificação internacional de equipamento móvel (IMEI):
- Método para receber a configuração da operadora:
getCarrierConfig
- Método para receber o tipo de rede para transmissão de dados:
getDataNetworkType
- Método para receber o tipo de rede do serviço de voz:
getVoiceNetworkType
- Métodos para receber informações sobre o app de SIM UICC (USIM):
- Número de série do chip:
getSimSerialNumber
- Informações do cartão:
getUiccCardsInfo
- GID1 (nível 1 do ID do grupo):
getGroupIdLevel1
- String do número de telefone para a linha 1:
getLine1Number
- Rede móvel terrestre pública (PLMN, na sigla em inglês) proibida:
getForbiddenPlmns
- PLMN equivalente da casa:
getEquivalentHomePlmns
- Número de série do chip:
- Métodos para receber ou definir um número de correio de voz:
- Método para enviar o código especial do discador:
sendDialerSpecialCode
- Método para redefinir o modem de rádio:
rebootModem
- Métodos para receber ou definir modos de seleção de rede:
- Método para solicitar uma verificação de rede:
requestNetworkScan
- Métodos para receber ou definir os tipos de rede permitidos/preferidos:
- Métodos para verificar se os dados móveis ou o roaming estão ativados 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 receber 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 da intensidade do sinal de rede celular:
Chamada de telefonia
TelephonyCallback
tem interfaces com um método de callback para
notificar o app de chamada quando os estados registrados mudarem:
- O indicador de mensagem aguardando foi alterado:
onMessageWaitingIndicatorChanged
- O indicador de encaminhamento de chamadas 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 mudou:
onPreciseDataConnectionStateChanged
- A lista de números de emergência atual foi alterada:
onEmergencyNumberListChanged
- O ID da assinatura de dados ativa foi alterado:
onActiveDataSubscriptionIdChanged
- A rede da operadora mudou:
onCarrierNetworkChange
- O registro de rede ou uma atualização de local/rota/área de rastreamento
falhou:
onRegistrationFailed
- As informações de bloqueio mudam:
onBarringInfoChanged
- A configuração atual do canal físico mudou:
onPhysicalChannelConfigChanged
SubscriptionManager
- Métodos para receber várias informações de assinatura:
- Método para receber o número de assinaturas ativas:
getActiveSubscriptionInfoCount
- Métodos para gerenciar grupos de assinatura:
- Métodos para receber ou definir a descrição do plano de relação de faturamento entre uma operadora e um assinante específico:
- Método para substituir temporariamente o plano de relacionamento de faturamento entre uma
operadora e um assinante específico para ser considerado sem medição:
setSubscriptionOverrideUnmetered
- Método para substituir temporariamente o plano de relação de faturamento entre um
operadora e um assinante específico para ser considerado congestionado:
setSubscriptionOverrideCongested
- Método para verificar se o app com o contexto fornecido está
autorizado a gerenciar a assinatura de acordo com os metadados:
canManageSubscription
SmsManager
- Método para permitir que o autor da chamada crie novas mensagens SMS recebidas:
injectSmsPdu
. - Método para enviar uma mensagem SMS de texto sem escrever no SMS
de nuvem:
sendTextMessageWithoutPersisting
CarrierConfigManager
- Método para notificar a mudança da configuração:
notifyConfigChangedForSubId
- Método para receber a configuração da operadora para a assinatura padrão:
getConfig
- Método para receber a configuração da operadora para a assinatura especificada:
getConfigForSubId
Para instruções, consulte Configuração do provedor de serviços.
BugreportManager
Método para iniciar um relatório de bug de conectividade, que é uma versão especializada do
o relatório do bug que inclui apenas informações para depurar problemas de conectividade relacionados
problemas:
startConnectivityBugreport
Gerenciador de estatísticas de rede
- Método para consultar o resumo do 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 callback de uso da rede:
ImsMmTelManager
- Métodos para registrar ou cancelar o registro do callback de registro IMS MmTel:
ImsRcsManager
- Métodos para registrar ou cancelar o registro do callback de registro de RCS do IMS:
- Métodos para receber o estado de registro IMS ou o tipo de transporte:
ProvisioningManager
- Métodos para registrar e cancelar o registro de atualizações de provisionamento de recursos IMS callback:
- Métodos relacionados ao status de provisionamento para o recurso IMS MmTel ou RCS:
Gestor Euicc
Método para mudar para (ativar) a assinatura especificada:
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 no arquivo de manifesto com
a permissão android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
e inclua um filtro de intent com a ação
#SERVICE_INTERFACE
. Os métodos incluem:
- Método para filtrar mensagens SMS recebidas:
onFilterSms
- Método para interceptar mensagens SMS enviadas do dispositivo:
onSendTextSms
- Método para interceptar mensagens SMS binárias enviadas pelo 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 de download de mensagens MMS recebidas:
onDownloadMms
CarrierService
Serviço que expõe funcionalidades específicas da operadora ao sistema. Para
estender essa classe, declare o serviço no arquivo de manifesto do app com a
permissão android.Manifest.permission#BIND_CARRIER_SERVICES
e
inclua um filtro de intent 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
a
true
nos metadados do serviço.
A plataforma vincula CarrierService
a sinalizações especiais para permitir que o
de serviço da operadora é executado em uma
bucket do App em espera. Isso isenta o app de serviço da operadora da
restrição de inatividade do app e aumenta a probabilidade de ele permanecer ativo quando a memória
do dispositivo estiver baixa. No entanto, se o app de serviço da operadora falhar por qualquer motivo,
ele perde todos os privilégios acima até que o app seja reiniciado e a vinculação seja
restabelecido. Por isso, é fundamental manter o app do serviço da operadora estável.
Os métodos em CarrierService
incluem:
- Para substituir e definir as configurações específicas da operadora:
onLoadConfig
- Para informar o sistema sobre uma mudança intencional futura na rede da operadora,
app 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 mais detalhes, consulte
a referência da classe Telephony
.
WifiNetworkSuggestion
Ao criar um objeto WifiNetworkSuggestion
, use os seguintes
métodos para definir um ID ou 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
incluir regras de privilégios da operadora como parte do UICC.
UiccCarrierPrivilegeRules.java
carrega regras, as analisa do cartão UICC e as armazena em cache na memória. Quando
uma verificação de privilégio for necessária, o UiccCarrierPrivilegeRules
vai comparar
certificado do autor da chamada com regras próprias, uma por uma. Se o UICC for removido, as
regras serão destruídas junto com o objeto UICC.
Validação
Para validar a implementação pelo
conjunto de teste de compatibilidade (CTS, na sigla em inglês) usando CtsCarrierApiTestCases.apk
,
é necessário ter um UICC de desenvolvedor com as regras corretas do UICC ou suporte ao ARF.
Peça ao fornecedor do chip de sua escolha para preparar um UICC do desenvolvedor com o
o ARF correto, conforme descrito nesta seção, e usar esse UICC para executar os testes. O
O UICC não exige serviço de rede celular ativo para passar em testes de CTS.
Preparar o UICC
Para o Android 11 e versões anteriores, o CtsCarrierApiTestCases.apk
é
assinado por aosp-testkey
, com o 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, o 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 os testes da API da operadora do CTS no Android 12, o dispositivo precisa usar um SIM com privilégios de operadora do CTS que atendam aos requisitos especificados na versão mais recente da especificação de terceiros do perfil de teste GSMA TS.48.
O mesmo chip também pode ser usado para versões anteriores à Android 12
Modificar o perfil de chip CTS
- Adicionar: privilégios de operadora do CTS no
mestre de app de regra de acesso (ARA-M) ou ARF. Ambas as assinaturas precisam ser
codificadas nas regras de privilégio da operadora:
- Hash1(SHA1):
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
- 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
- Hash1(SHA1):
- Criação: arquivos básicos USIM (EFs) do ADF não estão presentes na
TS.48 e necessário para o CTS:
- EF_MBDN (6FC7), tamanho do registro: 28, número do registro: 4
- Conteúdo
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
- Rec2-n: FF...FF
- Conteúdo
- 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ços 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 de nome da operadora Android CTS
nos EFs correspondentes que contêm essa 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)
Combinar a estrutura do perfil de teste
Faça o download e confira a versão mais recente das seguintes estruturas genéricas de perfil de teste. Esses perfis não terão a regra de privilégio de operadora CTS personalizada ou outras modificações listadas acima.
Executar testes
Para sua 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. CTS da API da operadora
Os testes oferecem suporte ao token sim-card-with-certs
do dispositivo. Por exemplo:
o seguinte token de dispositivo restringe a execução de testes de API da operadora 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, ele é executado em todos dispositivos.
Perguntas frequentes
Como os certificados podem ser atualizados no UICC?
A: Usar o mecanismo de atualização OTA do cartão
O UICC pode coexistir com outras regras?
A: É possível ter outras regras de segurança no UICC com o mesmo AID. A plataforma as filtra automaticamente.
O que acontece quando o UICC é removido de um app que depende dos certificados?
A: O app perde os 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?
A: A plataforma não limita o número de certificados, mas, como a verificação é linear, muitas regras podem causar latência na verificação.
Há um limite para o número de APIs que podem ser aceitas com esse método?
R: Não, mas limitamos o escopo a APIs relacionadas à operadora.
Algumas APIs estão proibidas de usar esse método? Se sim, como você as aplica? (ou seja, você tem testes para validar quais APIs são compatíveis com esse método?)
R: Consulte seção "Compatibilidade comportamental da API" da página "Compatibilidade do Android" Documento de definição de dados (CDD, na sigla em inglês). Temos alguns testes CTS para garantir que o modelo de permissão das APIs não será alterado.
Como isso funciona com o recurso de vários SIMs?
A: O SIM padrão especificado pelo usuário é usado.
De alguma forma, isso interage ou se sobrepõe a outras tecnologias de acesso SE, por exemplo, SEEK?
A: Por exemplo, o recurso SEEK usa o mesmo AID do UICC. Assim, as regras
coexistem e são filtradas por SEEK ou
UiccCarrierPrivileges
.
Quando é um bom momento para verificar os privilégios da operadora?
A: Depois da transmissão de carregamento do estado do chip.
Os OEMs podem desativar parte das APIs da operadora?
A: 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.
O setOperatorBrandOverride
substitui TODOS os outros tipos
de strings de nome
de operador? Por exemplo, SE13, UICC SPN ou NITZ com base em rede?
Sim, a substituição da marca do operador tem a maior prioridade. Quando definido, ele substitui TODAS as outras formas de strings de nome de operador.
O que a chamada de método injectSmsPdu
faz?
A: Esse método facilita o backup/restauração de SMS na nuvem. O
A chamada injectSmsPdu
ativa a função de restauração.
Para a filtragem de SMS, a chamada onFilterSms
é baseada na
filtragem de porta UDH de SMS? Ou os apps 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 oferecer suporte
a 32 bytes parece ser
incompatível com a especificação atual do GP (que permite apenas 0 ou 20 bytes). Por que
você está introduzindo essa mudança? O SHA-1 não é suficiente para
evitar colisões? Você já propôs essa mudança para o GP, já que ela pode
ser incompatível com o ARA-M/ARF?
A: Para oferecer segurança futura, essa 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 o SHA-256.
Se DeviceAppID
for 0 (vazio), você aplica a regra
todos os apps do dispositivo não cobertos por uma regra específica?
R: As APIs de operadoras exigem que DeviceAppID-REF-DO
seja preenchido.
O estado vazio é destinado a testes e não é recomendado para implantações
operacionais.
De acordo com a 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
. É de propósito? Como o código
se comporta quando apenas PKG-REF-DO
é usado em REF-DO
?
A: A opção de ter PKG-REF-DO
como um item de valor único
em REF-DO
foi removida na versão mais recente.
O PKG-REF-DO
só pode ocorrer em combinação com
DeviceAppID-REF-DO
.
Presumimos que possamos conceder acesso a todas as permissões baseadas na operadora ou ter um controle mais preciso. Em caso afirmativo, o que define o mapeamento entre a máscara de bit e as permissões reais? Uma permissão por turma? Uma permissão por método? 64 permissões separadas são suficientes a longo prazo?
A: Isso está reservado para o futuro, e aceitamos sugestões.
Você pode definir DeviceAppID
especificamente para o
Android? Este é o valor de hash SHA-1 (20 bytes) do editor
certificado usado para assinar o aplicativo em questão. Portanto, o nome não deve refletir isso.
propósito? (O nome pode ser confuso para muitos leitores, pois a regra é
aplicável a todos os apps assinados com esse mesmo Certificado de Editor.)
A: Os certificados de armazenamento DeviceAppID
têm suporte da especificação
atual. Tentamos minimizar as mudanças de especificação para reduzir a barreira para
adoção. Para mais detalhes, consulte as Regras do UICC.