UICC 이동통신사 권한

Android 5.1에서는 UICC(Universal Integrated Circuit Card) 앱의 소유자와 관련된 API의 특별 권한을 부여하는 메커니즘이 도입되었습니다. Android 플랫폼은 UICC에 저장된 인증서를 로드하고 이러한 인증서로 서명된 앱에 권한을 부여하여 몇 가지 특수 API를 호출합니다.

Android 7.0에서는 UICC 이동통신사 권한 규칙을 위한 기타 저장소 소스 지원을 위해 이 기능을 확장하여 API를 사용할 수 있는 이동통신사의 수를 극적으로 늘렸습니다. API 참조는 CarrierConfigManager에서 확인하고 도움말을 보려면 이동통신사 구성을 참조하세요.

이동통신사는 UICC를 완전히 제어하므로 이 메커니즘을 사용하면 Google Play와 같은 일반 앱 배포 채널에서 호스팅되는 모바일 네트워크 운영자(MNO)의 앱을 안전하고 유연하게 관리할 수 있습니다. 또한 기기별 플랫폼 인증서로 앱에 서명하거나 시스템 앱으로 사전 설치할 필요 없이 기기의 특수 권한을 유지할 수 있습니다.

UICC 규칙

UICC의 저장소는 GlobalPlatform 보안 요소 액세스 제어 사양과 호환됩니다. 카드의 애플리케이션 식별자(AID)는 A00000015141434C00이며 표준 GET DATA 명령어는 카드에 저장된 규칙을 가져오는 데 사용됩니다. 이러한 규칙은 카드 무선(OTA) 업데이트를 통해 업데이트할 수 있습니다.

데이터 계층 구조

UICC 규칙은 다음과 같은 데이터 계층 구조를 사용하며, 괄호 안의 문자 2개와 숫자 조합은 개체 태그입니다. 각 규칙은 REF-AR-DO(E2)이며 REF-DO와 AR-DO의 연결로 구성됩니다.

  • REF-DO(E1)에는 DeviceAppID-REF-DO 또는 DeviceAppID-REF-DO와 PKG-REF-DO의 연결이 포함됩니다.
    • DeviceAppID-REF-DO(C1)에는 인증서의 SHA-1(20바이트) 또는 SHA-256(32바이트) 서명이 저장됩니다.
    • PKG-REF-DO(CA)는 매니페스트에서 정의된 전체 패키지 이름 문자열이며 ASCII로 인코딩되고 최대 길이는 127바이트입니다.
  • AR-DO(E3)는 64개의 개별 권한을 나타내는 8바이트 비트 마스크인 PERM-AR-DO(DB)를 포함하도록 확장됩니다.

PKG-REF-DO가 없으면 인증서로 서명된 모든 앱에 액세스 권한이 부여됩니다. 그렇지 않은 경우 인증서와 패키지 이름이 모두 일치해야 합니다.

규칙 예

앱 이름은 com.google.android.apps.myapp이고 16진수 문자열의 SHA-1 인증서는 다음과 같습니다.

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

16진수 문자열의 UICC 규칙은 다음과 같습니다.

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

액세스 규칙 파일 지원

Android 7.0에는 액세스 규칙 파일(ARF)의 이동통신사 권한 규칙을 읽기 위한 지원 기능이 추가되었습니다.

Android 플랫폼은 먼저 액세스 규칙 애플리케이션(ARA) AID A00000015141434C00을 선택하려고 합니다. UICC에서 AID를 찾지 못한 경우에는 PKCS15 AID A000000063504B43532D3135를 선택하여 ARF로 대체합니다. 그러면 Android는 0x4300에서 액세스 제어 규칙 파일(ACRF)을 읽고 AID FFFFFFFFFFFF로 항목을 찾습니다. 다른 AID가 있는 항목은 무시되므로 다른 사용 사례의 규칙이 공존할 수 있습니다.

16진수 문자열의 ACRF 콘텐츠 예시:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

액세스 제어 조건 파일(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

위 예시에서 0x4310은 인증서 해시 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81을 포함하는 ACCF의 주소입니다. 이 인증서로 서명된 앱에는 이동통신사 권한이 부여됩니다.

사용 설정된 API

Android에서 지원하는 API는 다음과 같습니다.

TelephonyManager

TelephonyCallback

TelephonyCallback에는 등록된 상태가 변경되면 통화 앱에 알리는 콜백 메서드와의 인터페이스가 있습니다.

SubscriptionManager

SmsManager

CarrierConfigManager

자세한 내용은 이동통신사 구성을 참고하세요.

BugreportManager

연결 버그 신고(연결 관련 문제를 디버깅하는 정보만 포함하는 버그 신고의 특수한 버전)를 시작하는 메서드: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

지정된 구독으로 전환하는(지정된 구독을 사용 설정하는) 메서드: switchToSubscription

CarrierMessagingService

새 SMS 및 MMS가 전송되거나 수신되면 시스템에서 호출을 수신하는 서비스입니다. 이 클래스를 확장하려면 매니페스트 파일에서 android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE 권한으로 서비스를 선언하고 #SERVICE_INTERFACE 작업으로 인텐트 필터를 포함합니다. 메서드는 다음과 같습니다.

  • 수신 SMS 메시지를 필터링하는 메서드: onFilterSms
  • 기기에서 전송된 SMS 메시지를 가로채는 메서드: onSendTextSms
  • 기기에서 전송된 바이너리 SMS 메시지를 가로채는 메서드: onSendDataSms
  • 기기에서 전송된 긴 SMS 메시지를 가로채는 메서드: onSendMultipartTextSms
  • 기기에서 전송된 MMS 메시지를 가로채는 메서드: onSendMms
  • 수신된 MMS 메시지를 다운로드하는 메서드: onDownloadMms

CarrierService

시스템에 이동통신사 전용 기능을 노출하는 서비스입니다. 이 클래스를 확장하려면 앱 매니페스트 파일에서 android.Manifest.permission#BIND_CARRIER_SERVICES 권한으로 서비스를 선언하고 CARRIER_SERVICE_INTERFACE 작업으로 인텐트 필터를 포함합니다. 서비스에 수명이 긴 바인딩이 있으면 서비스의 메타데이터에서 android.service.carrier.LONG_LIVED_BINDING을 true로 설정합니다.

플랫폼은 이동통신사 서비스 프로세스가 특수한 앱 대기 버킷에서 실행되도록 특수 플래그를 사용하여 CarrierService를 바인딩합니다. 이렇게 하면 이동통신사 서비스 앱이 앱 유휴 제한에서 제외되며, 기기 메모리가 부족할 때 활성 상태를 유지할 가능성이 커집니다. 단, 어떠한 이유로든 이동통신사 서비스 앱이 비정상 종료되면 앱이 다시 시작되고 바인딩이 다시 설정될 때까지 위의 모든 권한을 잃게 됩니다. 따라서 이동통신사 서비스 앱을 안정적으로 유지하는 것이 중요합니다.

CarrierService의 메서드는 다음과 같습니다.

  • 이동통신사 전용 구성을 재정의하고 설정하는 메서드: onLoadConfig
  • 이동통신사 애플리케이션에 의해 실행될 의도적인 이동통신사 네트워크 변경사항을 알리는 메서드: notifyCarrierNetworkChange

전화통신 제공업체

전화통신 데이터베이스의 수정(삽입, 삭제, 업데이트, 쿼리)을 허용하는 콘텐츠 제공업체 API입니다. 값 필드는 Telephony.Carriers에 정의됩니다. 자세한 내용은 Telephony 클래스 참조를 참고하세요.

WifiNetworkSuggestion

WifiNetworkSuggestion 객체를 빌드할 때 다음 메서드를 사용하여 구독 ID 또는 구독 그룹을 설정합니다.

Android 플랫폼

감지된 UICC에서 플랫폼은 UICC의 일부로 이동통신사 권한 규칙이 포함된 내부 UICC 객체를 구성합니다. UiccCarrierPrivilegeRules.java는 규칙을 로드하여 UICC 카드에서 파싱하고 메모리에 캐시합니다. 권한 확인이 필요한 경우 UiccCarrierPrivilegeRules는 호출자 인증서를 자체 규칙과 하나씩 비교합니다. UICC가 삭제되면 규칙이 UICC 객체와 함께 삭제됩니다.

유효성 검사

CtsCarrierApiTestCases.apk를 사용하여 호환성 테스트 모음(CTS)을 통해 구현을 검증하려면 올바른 UICC 규칙이나 ARF 지원이 포함된 개발자 UICC가 있어야 합니다. 원하는 SIM 카드 공급업체에 이 섹션에서 설명하는 올바른 ARF가 포함된 개발자 UICC를 준비하고 이 UICC를 사용해 테스트를 실행하도록 요청하세요. CTS 테스트를 통과하는 데는 UICC에 활성 모바일 데이터 서비스가 필요하지 않습니다.

UICC 준비

Android 11 및 이전 버전에서는 CtsCarrierApiTestCases.apk가 aosp-testkey로 서명되며, 해시 값은 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81입니다.

Android 12부터는 CtsCarrierApiTestCases.apk가 cts-uicc-2021-testkey로 서명되며, 해시 값은 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입니다.

Android 12에서 CTS 이동통신사 API 테스트를 실행하려면 기기에서 최신 버전의 타사 GSMA TS.48 테스트 프로필 사양에 지정된 요구사항을 충족하는 CTS 이동통신사 권한으로 SIM을 사용해야 합니다.

Android 12 이전 버전에도 동일한 SIM을 사용할 수 있습니다.

CTS SIM 프로필 수정

  1. 추가: 액세스 규칙 애플리케이션 마스터(ARA-M) 또는 ARF에 CTS 이동통신사 권한을 추가합니다. 두 서명 모두 다음과 같은 이동통신사 권한 규칙으로 인코딩되어야 합니다.
    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
  2. 만들기: TS.48에 없으며 CTS에 필요한 ADF USIM EF(elementary file)를 만듭니다.
    1. EF_MBDN(6FC7), 레코드 크기: 28, 레코드 번호: 4 
      • 콘텐츠
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6(6FC8), 레코드 크기: 13, 레코드 번호: 1 
      • 콘텐츠: 00FF…FF
        1. EF_MBI(6FC9), 레코드 크기: 4, 레코드 번호: 1
      • 콘텐츠: Rec1: 01010101
        1. EF_MWIS(6FCA), 레코드 크기: 5, 레코드 번호: 1
      • 콘텐츠: 0000000000
  3. 수정 USIM 서비스 테이블: n°47, n°48의 서비스를 사용 설정합니다.
    1. EF_UST(6F38)
      • 콘텐츠: 9EFFBF1DFFFE0083410310010400406E01
  4. 수정: DF-5GS 파일 및 DF-SAIP 파일
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • 콘텐츠: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI(USIM/5FC0/4F02)
      • 콘텐츠: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info(USIM/5FC0/4F07)
      • 콘텐츠: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM(USIM/5FD0/4F01)
      • 콘텐츠: A0020000FF…FF
  5. 수정: 다음 지정이 포함된 각 EF에서 이동통신사 이름 문자열 Android CTS를 사용합니다.
    1. EF_SPN(USIM/6F46)
      • 콘텐츠: 01416E64726F696420435453FF..FF
    2. EF_PNN(USIM/6FC5)
      • 콘텐츠: Rec1 430B83413759FE4E934143EA14FF..FF

테스트 프로필 구조 매칭

다음과 같은 일반 테스트 프로필 구조의 최신 버전을 다운로드하고 매칭합니다. 이러한 프로필에는 위에 나열된 CTS 이동통신사 권한 규칙이 맞춤설정되어 있거나 수정되어 있지 않습니다.

테스트 실행

편의성을 위해 CTS는 테스트를 동일한 토큰으로 구성된 기기에서만 실행되도록 제한하는 기기 토큰을 지원합니다. 이동통신사 API CTS 테스트는 기기 토큰 sim-card-with-certs를 지원합니다. 예를 들어 다음 기기 토큰은 이동통신사 API 테스트를 기기 abcd1234에서만 실행되도록 제한합니다.

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

기기 토큰을 사용하지 않고 테스트를 실행하면 테스트가 모든 기기에서 실행됩니다.

FAQ

UICC에서는 인증서를 어떻게 업데이트하나요?

A: 기존 카드 OTA 업데이트 메커니즘을 사용합니다.

UICC가 다른 규칙과 공존할 수 있나요?

A: 동일한 AID로 UICC에 다른 보안 규칙이 있는 것은 괜찮습니다. 플랫폼에서 자동으로 필터링합니다.

인증서에 의존하는 앱의 UICC가 삭제되면 어떻게 되나요?

A: UICC를 삭제할 때 UICC와 관련된 규칙이 제거되므로 앱이 권한을 잃습니다.

UICC의 인증서 수에 제한이 있나요?

A: 플랫폼은 인증서 수를 제한하지 않지만 검사가 선형이므로 규칙 수가 너무 많으면 검사가 지연될 수 있습니다.

이 메서드로 지원할 수 있는 API 수에 제한이 있나요?

A: 아니요. 하지만 이동통신사 관련 API로 범위를 제한합니다.

이 메서드의 사용이 금지된 API가 있나요? 있다면 어떻게 적용해야 하나요? (즉, 어떤 API가 이 메서드를 통해 지원되는지 확인하기 위한 테스트가 있나요?)

A: Android 호환성 정의 문서(CDD)의 API 동작 호환성 섹션을 참고하세요. API 권한 모델이 변경되지 않도록 하는 CTS 테스트가 있습니다.

멀티 SIM 기능과는 어떻게 호환되나요?

A: 사용자가 지정한 기본 SIM이 사용됩니다.

어떤 방식으로든 SEEK와 같은 다른 SE 액세스 기술과 상호작용하거나 중복되나요?

A: 예를 든 SEEK는 UICC와 동일한 AID를 사용합니다. 따라서 규칙이 공존하고 SEEK 또는 UiccCarrierPrivileges에서 필터링됩니다.

이동통신사 권한은 언제 확인하면 좋을까요?

A: SIM 상태가 브로드캐스트를 로드한 이후가 좋습니다.

OEM이 이동통신사 API의 일부를 사용 중지할 수 있나요?

A: 아니요. Google은 현재 API가 최소 집합이라고 생각하며 향후 더 나은 세부 제어를 위해 비트 마스크를 사용할 계획입니다.

setOperatorBrandOverride는 다른 모든 형식의 연산자 이름 문자열을 재정의하나요? 예를 들어 SE13, UICC SPN 또는 네트워크 기반 NITZ는 어떤가요?

예. 연산자 브랜드 재정의의 우선순위가 가장 높습니다. 이 필드가 설정되면 다른 모든 형식의 연산자 이름 문자열을 재정의합니다.

injectSmsPdu 메서드 호출은 어떤 작업을 하나요?

A: 이 메서드는 클라우드에서 SMS 백업/복원을 용이하게 합니다. injectSmsPdu 호출은 복원 기능을 사용 설정합니다.

SMS 필터링의 경우 onFilterSms 호출이 SMS UDH 포트 필터링을 기반으로 하나요? 아니면 이동통신사 앱이 수신되는 모든 SMS에 액세스할 수 있나요?

A: 이동통신사는 모든 SMS 데이터에 액세스할 수 있습니다.

32바이트를 지원하기 위한 DeviceAppID-REF-DO 확장 프로그램은 현재 GP 사양(0 또는 20바이트만 허용)과 호환되지 않는 것 같습니다. 그렇다면 왜 이러한 변경사항을 도입하려는 건가요? SHA-1이 충돌을 방지하는 데 충분하지 않나요? 이러한 변경사항을 이미 GP에 제안했나요? 기존 ARA-M/ARF와 호환되지 않을 수 있을 테니까요.

A: 미래에 대비한 보안을 제공하기 위해 이 확장 프로그램은 현재 GP SEAC 표준에서 유일한 옵션인 SHA-1 외에 DeviceAppID-REF-DO의 SHA-256을 도입합니다. SHA-256을 사용할 것을 적극적으로 권장합니다.

DeviceAppID가 0(비어 있음)인 경우 특정 규칙이 적용되지 않는 모든 기기 앱에 규칙을 적용하나요?

A: 이동통신사 API는 DeviceAppID-REF-DO가 채워지도록 요구합니다. 비어 있으면 테스트 목적을 위한 것이며 운영 배포에는 권장되지 않습니다.

사양에 따라 DeviceAppID-REF-DO 없이 자체로만 사용되는 PKG-REF-DO는 허용되면 안 됩니다. 그러나 여전히 사양의 표 6-4에 REF-DO 정의의 확장으로 설명되어 있습니다. 의도된 것인가요? PKG-REF-DO만 REF-DO에서 사용되면 코드는 어떻게 동작하나요?

A: REF-DO에서 단일 값 항목으로 PKG-REF-DO가 있는 옵션은 최신 버전에서 삭제되었습니다. PKG-REF-DO은 DeviceAppID-REF-DO과 함께 사용해야 합니다.

모든 이동통신사 기반 권한에 액세스하는 권한을 부여하거나 세분화된 제어를 할 수 있다고 가정합니다. 그렇다면 비트 마스크와 실제 권한 사이의 매핑을 정의하는 것은 무엇인가요? 클래스당 권한 1개인가요? 메서드당 권한 1개인가요? 결과적으로 별도 권한 64개가 충분한가요?

A: 향후에 논의해 봐야 할 사안이지만 언제든지 제안해 주세요.

Android용 DeviceAppID를 좀 더 구체적으로 정의할 수 있나요? 이 ID는 주어진 앱에 서명하는 데 사용된 게시자 인증서의 SHA-1(20바이트) 해시 값이므로 이름에 그 목적을 반영하면 안 되나요? 현재 이름은 많은 리더에 혼동을 줄 수 있습니다. 규칙이 동일한 게시자 인증서로 서명된 모든 앱에 적용되기 때문입니다.

A: 인증서가 저장된 DeviceAppID는 기존 사양에서 지원됩니다. Google에서는 사양 변경을 최소화하여 채택 장벽을 낮추려고 했습니다. 자세한 내용은 UICC 규칙을 참조하세요.