UICC 이동통신사 권한

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

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

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

UICC 규칙

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

데이터 계층 구조

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

  • REF-DO(E1)에는 DeviceAppID-REF-DO 또는 DeviceAppID-REF-DOPKG-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
    

액세스 규칙 파일(ARF) 지원

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

SmsManager

호출자가 새로운 수신 SMS 메시지를 만들 수 있는 메서드: injectSmsPdu

CarrierConfigManager

구성이 변경되었음을 알리기 위한 메서드: notifyConfigChangedForSubId 자세한 내용은 이동통신사 구성을 참조하세요.

CarrierMessagingService

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

전화통신 제공업체

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

Android 플랫폼

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

유효성 검사

호환성 테스트 도구 모음(CTS)에는 CtsCarrierApiTestCases.apk의 이동통신사 API와 관련된 테스트가 포함됩니다. 이 기능은 UICC의 인증서에 종속되므로 이러한 테스트를 통과하도록 UICC를 준비해야 합니다.

UICC 준비

기본적으로 CtsCarrierApiTestCases.apk는 해시 값 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81과 함께 Android 개발자 키로 서명됩니다. 테스트는 UICC의 인증서가 일치하지 않으면 예상 인증서 해시도 출력합니다.

출력 예:

    junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
    Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
    

CtsCarrierApiTestCases.apk를 사용하여 CTS를 통해 구현을 검증하려면 올바른 UICC 규칙이나 ARF 지원이 포함된 개발자 UICC가 있어야 합니다. 원하는 SIM 카드 공급업체에 이 섹션에서 설명하는 올바른 ARF가 포함된 개발자 UICC를 준비하고 해당 UICC를 사용해 테스트를 실행하도록 요청할 수 있습니다. UICC에는 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는 어떤가요?

A: TelephonyManager에서 SPN 항목을 참조하세요.

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-DOREF-DO에서 사용되면 코드는 어떻게 동작하나요?

A: REF-DO에서 단일 값 항목으로 PKG-REF-DO가 있는 옵션은 최신 버전에서 삭제되었습니다. PKG-REF-DODeviceAppID-REF-DO와의 조합으로만 발생해야 합니다.

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

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

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

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