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). A 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 UICC as regras de privilégio das operadoras, drasticamente aumentar 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, portanto, esse mecanismo fornece uma maneira segura e flexível de gerenciar apps da operadora de rede móvel (MNO) hospedados em canais genéricos de distribuição de apps (como o Google Play), enquanto mantém privilégios especiais em dispositivos e sem a necessidade de assinar aplicativos com o certificado de plataforma por dispositivo ou a pré-instalação como um app do sistema.
Regras do UICC
O armazenamento no UICC é compatível com o
Plataforma global
especificação do controle de acesso do elemento de segurança. O identificador do app
(AID) do cartão é A00000015141434C00
, e o valor padrão
GET DATA
é usado para buscar as regras armazenadas no card. É possível atualizar essas regras
com atualizações OTA (card over the air).
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çãoDeviceAppID-REF-DO
ePKG-REF-DO
.- O
DeviceAppID-REF-DO
(C1
) armazena o SHA-1. (20 bytes) ou SHA-256 (32 bytes) do certificado. PKG-REF-DO
(CA
) é o nome completo do pacote string definida no manifesto, codificada em ASCII, comprimento máximo de 127 bytes.
- O
- O
AR-DO
(E3
) foi estendido para incluirPERM-AR-DO
(DB
), que é um bit de 8 bytes máscara 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 à leitura das regras de privilégio da operadora pelo 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 PKCS15 AID
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 na 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 de 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 ativadas
O Android é compatível com as seguintes APIs.
Gerente de telefonia
- 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 a permissão da operadora
privilégios:
hasCarrierPrivileges
. - Métodos para substituir marca e número:
- Métodos para comunicação direta do UICC:
- Método para definir o modo do dispositivo como global:
setPreferredNetworkTypeToGlobal
. - Métodos para receber as identidades do dispositivo ou da rede:
- Identificação internacional de equipamento móvel (IMEI, na sigla em inglês):
getImei
- Identificador de equipamento móvel (MEID, na sigla em inglês):
getMeid
- Identificador de acesso à rede (NAI, na sigla em inglês):
getNai
- Número de série do chip:
getSimSerialNumber
- Identificação internacional de equipamento móvel (IMEI, na sigla em inglês):
- Método para obter 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 UICC SIM (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 proibida (PLMN, na sigla em inglês):
getForbiddenPlmns
- PLMN doméstica equivalente:
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 por 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 celular:
Chamada de telefonia
TelephonyCallback
tem interfaces com um método de callback para
notificar o app de chamada quando os estados registrados mudarem:
- Indicador de mensagem em espera alterado:
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 mudou:
onPreciseDataConnectionStateChanged
- A lista de números de emergência atual mudou:
onEmergencyNumberListChanged
- O ID da assinatura de dados ativa mudou:
onActiveDataSubscriptionIdChanged
- A rede da operadora foi alterada:
onCarrierNetworkChange
- O registro da rede ou uma atualização de local/roteamento/rastreamento
falhou:
onRegistrationFailed
- As informações de bloqueio mudam:
onBarringInfoChanged
- A configuração atual do canal físico mudou:
onPhysicalChannelConfigChanged
Gerenciador de inscrições
- 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 relação de faturamento entre um
operadora e um assinante específico para serem considerados ilimitados:
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 em questão de acordo com os respectivos metadados:
canManageSubscription
Gerenciador de SMS
- 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
TransportadoraConfigManager
- 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 da operadora.
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 a conectividade relacionada
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 de 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 RCS do IMS:
- Métodos para receber o estado de registro IMS ou o tipo de transporte:
Gerenciador de provisionamento
- Métodos para registrar e cancelar o registro de atualizações de provisionamento de recursos IMS callback:
- Métodos relacionados ao status de provisionamento do recurso IMS MmTel ou RCS:
Gestor Euicc
Método para mudar para (ativar) a assinatura especificada:
switchToSubscription
Serviço de mensagens da operadora
Serviço que recebe chamadas do sistema quando novas mensagens SMS e MMS são enviadas ou
recebidos. Para estender essa classe, declare o serviço no arquivo de manifesto com
android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
e incluir um filtro de intent com a #SERVICE_INTERFACE
à ação. 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 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 de download de mensagens MMS recebidas:
onDownloadMms
Serviço da operadora
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 aplicativo com 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 de
restrição de inatividade do app e aumenta a probabilidade de que ele permaneça ativo quando o dispositivo
com pouca memória. 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 de provedores de conteúdo para permitir modificações (inserir, excluir, atualizar, consultar)
ao 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
Sugestão de rede Wi-Fi
Ao criar um objeto WifiNetworkSuggestion
, use o seguinte
métodos para definir um ID de assinatura ou um grupo de assinaturas:
- Método para definir um ID de assinatura:
setSubscriptionId
- Metohd 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, o
são destruídas junto com o objeto UICC.
Validação
Para validar a implementação por meio de
Conjunto de teste de compatibilidade (CTS) usando CtsCarrierApiTestCases.apk
,
você deve ter um UICC de desenvolvedor com as regras UICC corretas ou suporte a 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. A
O UICC não exige serviço de rede celular ativo para passar em testes de CTS.
Preparar o UICC
No Android 11 e versões anteriores, o 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, 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 testes de API da operadora CTS no Android 12, o dispositivo precisa usar um chip com operadora CTS privilégios que atendem aos requisitos especificados na versão mais recente do o terceiro especificação GSMA TS.48 Test Profile.
O mesmo chip também pode ser usado para versões anteriores à Android 12
Modificar o perfil do chip do CTS
- Adicionar:privilégios da operadora do CTS em
mestre de app de regra de acesso (ARA-M, na sigla em inglês) ou ARF. As duas assinaturas precisam ser
codificado 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 de registro: 4
- Conteúdo
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
- Rec2-n: FF...FF
- Conteúdo
- EF_EXT6 (6FC8), tamanho do registro:13, número de registro: 1
- Conteúdo: 00FF...FF
- EF_MBI (6FC9), tamanho do registro: 4, número de 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 de 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
nas respectivas EFs 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)
Corresponder à estrutura do perfil de teste
Faça o download e associe a versão mais recente das seguintes estruturas genéricas de perfis de teste. Esses perfis não terão a regra de privilégio da operadora do CTS personalizada ou outras modificações listados acima.
Executar testes
Por conveniência, o CTS oferece suporte a um token do dispositivo que restringe
sejam executados 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?
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 de um app que depende do certificados nele?
A: O app perde os privilégios porque as regras associadas ao O UICC é destruído na remoção dele.
Existe um limite para o número de certificados no UICC?
A: A plataforma não limita o número de certificados. mas, como o a verificação é linear, e muitas regras podem causar latência na verificação.
Existe um limite para o número de APIs que podemos dar suporte com isso? método?
R: Não, mas limitamos o escopo a APIs relacionadas a operadoras.
Algumas APIs são proibidas de usar esse método? Em caso afirmativo, como você as aplica? (ou seja, você tem testes para validar quais APIs estão compatíveis com esse método?)
R: Consulte seção "Compatibilidade comportamental da API" de "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 chips?
A: É usado o chip padrão especificado pelo usuário.
Isso interage ou se sobrepõe a outro acesso de engenheiro de vendas tecnologias, por exemplo, SEEK?
A: Por exemplo, o recurso SEEK usa o mesmo AID do UICC. Portanto, as regras
coexistem e são filtradas pelas buscas
UiccCarrierPrivileges
.
Quando é um bom momento para verificar os privilégios da operadora?
A: Após a transmissão do estado do chip carregado.
Os OEMs podem desativar parte das APIs de operadoras?
R: Não. Acreditamos que as APIs atuais são o conjunto mínimo e nós mas planejamos usar a bitmask para ter um controle de granularidade mais refinado no futuro.
O setOperatorBrandOverride
substitui TODOS os outros formulários
de operador
nomear strings? Por exemplo, SE13, UICC SPN ou NITZ com base em rede?
Sim, a substituição da marca do operador tem a prioridade mais alta. Quando definido, ele substitui TODOS 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. A
A chamada injectSmsPdu
ativa a função de restauração.
Para a filtragem de SMS, a chamada onFilterSms
tem como base
Filtragem de portas SMS UDH? 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 do DeviceAppID-REF-DO
para oferecer suporte
parece que 32 bytes foram
incompatível com a especificação GP atual (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 alteração ao GP, porque isso poderia
é incompatível com versões anteriores da ARA-M/ARF?
R: Para oferecer segurança preparada para o futuro, essa extensão introduz o 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 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.
Estar vazio é para fins de teste e não é recomendado para fins operacionais
implantações.
.
De acordo com suas especificações, PKG-REF-DO
usado apenas por
em si, 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 comportam quando apenas PKG-REF-DO
é usado em REF-DO
?
A: a opção de usar PKG-REF-DO
como um único valor
O item em REF-DO
foi removido na versão mais recente.
PKG-REF-DO
deve ocorrer somente 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 o bit máscara 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? .
R: Esse documento ficará reservado para o futuro, e sugestões serão bem-vindas.
Você consegue definir melhor DeviceAppID
para Android?
especificamente? 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.)
R: O DeviceAppID
de armazenamento de certificados tem suporte do
especificação atual. Tentamos minimizar mudanças nas especificações para reduzir a barreira
da adoção de produtos. Para mais detalhes, consulte as Regras do UICC.