UICC 이동통신사 권한

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

Android 7.0에서는 UICC 이동통신사 권한 규칙을 위한 ARF(Access Rule File) 등의 기타 저장소 소스 지원을 위해 이 기능을 확장하여 API 사용이 가능한 이동통신사의 수를 극적으로 늘렸습니다. API 참조 문서는 CarrierConfigManager를, 관련 지침은 이동통신사 구성을 참조하세요.

일부 이동통신사는 UICC에 대한 온전한 제어성을 보유합니다. 따라서 이러한 메커니즘은 Google Play와 같은 일반 애플리케이션 배포 채널에서 호스팅되는 MNO(Mobile Network Operator)의 앱을 관리하는 동시에 기기별 플랫폼 인증서로 앱을 서명하거나 시스템 앱으로 미리 설치할 필요 없이 기기의 특수 권한을 유지할 수 있는 안전하고 유연한 방식을 제공합니다.

UICC 규칙

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

데이터 계층 구조

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
    

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

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

Android 플랫폼은 먼저 ARA(액세스 규칙 애플릿) AID(애플리케이션 식별자) A00000015141434C00을 선택하려고 시도합니다. UICC(Universal Integrated Circuit Card)에서 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

  • 이동통신사 애플리케이션이 UICC에 보안 질문/응답을 물을 수 있게 해주는 API: getIccAuthentication.
  • 애플리케이션 호출에 이동통신사 권한이 부여되었는지 확인하기 위한 API : hasCarrierPrivileges.
  • 브랜드 및 번호 재정의를 위한 API:
    • setOperatorBrandOverride
    • setLine1NumberForDisplay
    • setVoiceMailNumber
  • 직접적인 UICC 통신을 위한 API:
    • iccOpenLogicalChannel
    • iccCloseLogicalChannel
    • iccExchangeSimIO
    • iccTransmitApduLogicalChannel
    • iccTransmitApduBasicChannel
    • sendEnvelopeWithStatus
  • 기기 모드를 전역으로 설정하기 위한 API: setPreferredNetworkTypeToGlobal.

SmsManager

호출자가 새로 수신되는 SMS 메시지를 생성할 수 있게 해주는 API: injectSmsPdu.

CarrierConfigManager

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

CarrierMessagingService

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

  • onFilterSms
  • onSendTextSms
  • onSendDataSms
  • onSendMultipartTextSms
  • onSendMms
  • onDownloadMms

TelephonyProvider

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

Android 플랫폼

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

유효성 검사

Android 7.0 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을 포함합니다. 테스트는 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 테스트를 합격할 수 있습니다.

테스트 실행하기

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

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

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

FAQ

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

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

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

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-DO만 REF-DO에 사용된 경우의 동작은 어떻게 되나요?

A: REF-DO에서 단일 값으로 PKG-REF-DO를 취하는 옵션은 최신 버전에서 제거되었습니다. PKG-REF-DO는 DeviceAppID-REF-DO와의 조합에서만 발생해야 합니다.

저희는 모든 이동통신사 기반 권한을 부여하거나 세부적인 제어 권한을 보유할 수 있다고 가정합니다. 그렇다면 비트 마스크와 실제 권한 간의 매핑은 무엇에 의해 정의되나요? 클래스당 권한 1개인가요? 구체적으로는 메서드당 권한 1개인가요? 장기적으로는 64개의 별도 권한으로 충분할까요?

A: 이는 향후를 위해 유보되어 있지만 제안은 언제든 환영입니다.

Android용 DeviceAppID를 좀 더 구체적으로 정의할 수 있나요? 이것이 앱을 서명하는 데 사용된 게시자 인증서의 SHA-1(20바이트) 해시 값이면 이름이 목적을 반영해야 하지 않나요? 그렇다면 규칙이 같은 게시자 인증서로 서명된 모든 앱에 적용될 수 있으므로 다수의 리더가 이름을 혼동할 수 있습니다.

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