UICC Carrier Privileges

UICC Carrier Privileges

Android 5.1 introduced a new mechanism to grant special privileges for APIs relevant to the Universal Integrated Circuit Card (UICC) owner’s apps. The Android platform will load certificates stored on a UICC and grant permission to apps signed by these certificates to make calls to a handful of special APIs. Since carriers have full control of the UICC, this mechanism provides a secure and flexible way to manage apps from the Mobile Network Operator (MNO) hosted on generic application distribution channels such as Google Play but still have special privileges on devices without the need for the apps to be signed by the per-device platform certificate or be pre-installed as a system app.

Rules on UICC

---

Storage on the UICC is compatible with the GlobalPlatform Secure Element Access Control specification. The application identifier (AID) on card is A00000015141434C00, and the standard GET DATA command is used to fetch rules stored on the card. You may update these rules via card over-the-air (OTA) update. Data hierarchy is as follows (noting the two-character letter and number combination in parentheses is the object tag). (An extension to spec is under review.)

Each rule is a REF-AR-DO (E2) and consists of a concatenation of a REF-DO and an AR-DO:

• REF-DO (E1) contains a DeviceAppID-REF-DO or a concatenation of a DeviceAppID-REF-DO and a PKG-REF-DO.
  • DeviceAppID-REF-DO (C1) stores the SHA1 (20 bytes) or SHA256 (32 bytes) signature of the certificate.
  • PKG-REF-DO (CA) is the full package name string defined in manifest, ASCII encoded, max length 127 bytes.
• AR-DO (E3) is extended to include PERM-AR-DO (DB), which is an 8-byte bit mask representing 64 separate permissions.

If PKG-REF-DO is not present, any app signed by the certificate will be granted access; otherwise both certificate and package name need to match.

Example

App name: com.google.android.apps.myapp
Sha1 of certificate in hex string:

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

Rule on UICC in hex string:

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

Enabled APIs

---

Currently we support the following APIs, listed below (refer to developer.android.com for more details).

TelephonyManager

API to check whether calling application has been granted carrier privileges:

hasCarrierPrivileges

APIs for brand and number override:

setOperatorBrandOverride
setLine1NumberForDisplay
setVoiceMailNumber

APIs for direct UICC communication:

iccOpenLogicalChannel
iccCloseLogicalChannel
iccExchangeSimIO
iccTransmitApduLogicalChannel
iccTransmitApduBasicChannel
sendEnvelopeWithStatus

API to set device mode to global:

setPreferredNetworkTypeToGlobal

SmsManager

API allows caller to create new incoming SMS messages:

injectSmsPdu

CarrierMessagingService

A service that receives calls from the system when new SMS and MMS are sent or received. To extend this class, you must declare the service in your manifest file with the android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE permission and include an intent filter with the #SERVICE_INTERFACE action.

onFilterSms
onSendTextSms
onSendDataSms
onSendMultipartTextSms
onSendMms
onDownloadMms

TelephonyProvider

Content provider APIs that allow modification to the telephony database, value fields are defined at Telephony.Carriers:

insert, delete, update, query

See the Telephony reference on developer.android.com for additional information.

Android platform

---

On a detected UICC, the platform will construct internal UICC objects that include carrier privilege rules as part of the UICC. UiccCarrierPrivilegeRules.java will load rules, parse them from the UICC card, and cache them in memory. When a privilege check is needed, UiccCarrierPrivilegeRules will compare the caller certificate with its own rules one by one. If the UICC is removed, rules will be destroyed along with the UICC object.

FAQ

---

How can certificates be updated on the UICC?

A: Use existing card OTA update mechanism.

Can it co-exist with other rules?

A: It’s fine to have other security rules on the UICC under same AID; the platform will filter them out automatically.

What happens when the UICC is removed for an app that relies on the certificates on it?

A: The app will lose its privileges because the rules associated with the UICC are destroyed on UICC removal.

Is there a limit on the number of certificates on the UICC?

A: The platform doesn’t limit the number of certificates; but because the check is linear, too many rules may incur a latency for check.

Is there a limit to number of APIs we can support via this method?

A: No, but we limit the scope of APIs to carrier related.

Are there some APIs prohibited from using this method? If so, how do you enforce them? (ie. Will you have tests to validate which APIs are supported via this method?)

A: Please refer to the "API Behavioral Compatibility" section of the Android Compatibility Definition Document CDD). We have some CTS tests to make sure the permission model of the APIs is not changed.

How does this work with the multi-SIM feature?

A: The default SIM that gets set by the user will be used.

Does this in any way interact or overlap with other SE access technologies e.g. SEEK? A: As an example, SEEK uses the same AID as on the UICC. So the rules co-exist and are filtered by either SEEK or UiccCarrierPrivileges.

When is it a good time to check carrier privileges? A: After the SIM state loaded broadcast.

Can OEMs disable part of carrier APIs?

A: No. We believe current APIs are the minimal set, and we plan to use the bit mask for finer granularity control in the future.

Does setOperatorBrandOverride override ALL other forms of operator name strings? For example, SE13, UICC SPN, network based NITZ, etc.?

A: See the SPN entry within TelephonyManager: http://developer.android.com/reference/android/telephony/TelephonyManager.html

What does the injectSmsPdu method call do?

A: This facilitates SMS backup/restore in the cloud. The injectSmsPdu call enables the restore function.

For SMS filtering, is the onFilterSms call based on SMS UDH port filtering? Or would carrier apps have access to ALL incoming SMS?

A: Carriers have access to all SMS data.

Since the extension of DeviceAppID-REF-DO to support 32 bytes appears incompatible with the current GP spec (which allows 0 or 20 bytes only) why are you introducing this change? Do you not consider SHA-1 to be good enough to avoid collisions? Have you proposed this change to GP already, as this could be backwards incompatible with existing ARA-M / ARF?

A: For providing future proof security this extension introduces SHA-256 for DeviceAppID-REF-DO in addition to SHA-1 which is currently the only option in the GP SEAC standard. It is highly recommended to use SHA-256.

If DeviceAppID is 0 (empty), would you really apply the rule to all device applications not covered by a specific rule?

A: Carrier apis require deviceappid-ref-do be non-empty. Being empty is intended for test purpose and is not recommended for operational deployments.

According to your spec, PKG-REF-DO used just by itself, without DeviceAppID-REF-DO, should not be accepted. But it is still described in Table 6-4 as extending the definition of REF-DO. Is this on purpose? What will be the behavior of the code when only a PKG-REF-DO is used in a REF-DO?

A: The option of having PKG-REF-DO as a single value item in REF-DO was removed in the latest version. PKG-REF-DO should only occur in combination with DeviceAppID-REF-DO.

We assume we can grant access to all carrier-based permissions or have a finer-grained control. What will define the mapping between the bit mask and the actual permissions then? One permission per class? One permission per method specifically? Will 64 separate permissions be enough in the long run?

A: This is reserved for the future, and we welcome suggestions.

Can you further define the DeviceAppID for Android specifically? Since this is the SHA-1 (20 bytes) hash value of the Publisher certificate used to signed the given app, shouldn't the name reflect that purpose? (The name could be confusing to many readers as the rule will be applicable then to all apps signed with that same Publisher certificate.)

A: See the Rules on UICC section for details. The deviceAppID storing certificates is already supported by the existing spec. We tried to minimize spec changes to lower barrier for adoption.