امتیازات اپراتور UICC

اندروید ۵.۱ مکانیزمی را برای اعطای امتیازات ویژه به APIهای مربوط به دارندگان برنامه‌های کارت مدار مجتمع جهانی (UICC) معرفی کرد. پلتفرم اندروید گواهی‌های ذخیره شده در UICC را بارگذاری می‌کند و به برنامه‌هایی که توسط این گواهی‌ها امضا شده‌اند، اجازه می‌دهد تا با تعداد انگشت‌شماری از APIهای ویژه تماس برقرار کنند.

اندروید ۷.۰ این ویژگی را برای پشتیبانی از سایر منابع ذخیره‌سازی برای قوانین امتیاز اپراتور UICC گسترش داده است و تعداد اپراتورهایی را که می‌توانند از APIها استفاده کنند، به طرز چشمگیری افزایش داده است. برای مرجع API، به CarrierConfigManager مراجعه کنید؛ برای دستورالعمل‌ها، به Carrier Configuration مراجعه کنید.

اپراتورها کنترل کامل UICC را دارند، بنابراین این مکانیسم روشی امن و انعطاف‌پذیر برای مدیریت برنامه‌های اپراتور شبکه تلفن همراه (MNO) که در کانال‌های توزیع عمومی برنامه (مانند Google Play) میزبانی می‌شوند، فراهم می‌کند، در حالی که امتیازات ویژه را در دستگاه‌ها حفظ می‌کند و نیازی به امضای برنامه‌ها با گواهی پلتفرم هر دستگاه یا نصب اولیه به عنوان یک برنامه سیستمی ندارد.

قوانین مربوط به UICC

ذخیره‌سازی در UICC با مشخصات GlobalPlatform Secure Element Access Control سازگار است. شناسه برنامه (AID) روی کارت A00000015141434C00 است و از دستور استاندارد GET DATA برای دریافت قوانین ذخیره شده روی کارت استفاده می‌شود. می‌توانید این قوانین را از طریق به‌روزرسانی‌های کارت از طریق بی‌سیم (OTA) به‌روزرسانی کنید.

سلسله مراتب داده

قوانین UICC از سلسله مراتب داده زیر استفاده می‌کنند (ترکیب دو کاراکتری حرف و عدد داخل پرانتز، برچسب شیء است). هر قانون 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، حداکثر طول ۱۲۷ بایت.
  • AR-DO ( E3 ) گسترش یافته است تا PERM-AR-DO ( DB ) را نیز شامل شود، که یک ماسک بیتی ۸ بایتی است که ۶۴ مجوز جداگانه را نشان می‌دهد.

اگر PKG-REF-DO وجود نداشته باشد، به هر برنامه‌ای که توسط گواهی امضا شده باشد، دسترسی داده می‌شود؛ در غیر این صورت، هم گواهی و هم نام بسته باید مطابقت داشته باشند.

مثال قانون

نام برنامه com.google.android.apps.myapp است و گواهی SHA-1 در رشته هگز به صورت زیر است:

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

قانون UICC در رشته هگز به صورت زیر است:

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

پشتیبانی از فایل قوانین دسترسی

اندروید ۷.۰ پشتیبانی از خواندن قوانین امتیاز حامل از فایل قانون دسترسی (ARF) را اضافه کرده است.

پلتفرم اندروید ابتدا تلاش می‌کند تا برنامه‌ی قواعد دسترسی (ARA) با شناسه‌ی A00000015141434C00 را انتخاب کند. اگر AID را در UICC پیدا نکند، با انتخاب PKCS15 AID A000000063504B43532D3135 به ARF برمی‌گردد. سپس اندروید فایل قواعد کنترل دسترسی (ACRF) را در 0x4300 می‌خواند و به دنبال ورودی‌هایی با شناسه‌ی AID FFFFFFFFFFFF می‌گردد. ورودی‌هایی با AIDهای مختلف نادیده گرفته می‌شوند، بنابراین قوانین مربوط به سایر موارد استفاده می‌توانند همزمان وجود داشته باشند.

مثال محتوای 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 آدرس ACCF است که شامل هش گواهی 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . برنامه‌هایی که توسط این گواهی امضا شده‌اند، دارای امتیازات اپراتور هستند.

API های فعال شده

اندروید از API های زیر پشتیبانی می کند.

مدیر تلفن

تماس تلفنی

TelephonyCallback رابط‌هایی با یک متد callback دارد که هنگام تغییر وضعیت‌های ثبت‌شده، به برنامه‌ی فراخوانی‌کننده اطلاع می‌دهد:

مدیر اشتراک

مدیر پیامک

  • روشی که به تماس‌گیرنده اجازه می‌دهد پیامک‌های دریافتی جدید ایجاد کند: injectSmsPdu .
  • روشی برای ارسال پیامک متنی بدون نوشتن در ارائه دهنده پیامک: sendTextMessageWithoutPersisting

مدیر پیکربندی حامل

  • روش اعلام تغییر پیکربندی: notifyConfigChangedForSubId .
  • روش دریافت پیکربندی اپراتور برای اشتراک پیش‌فرض: getConfig
  • روش دریافت پیکربندی اپراتور برای اشتراک مشخص شده: getConfigForSubId

برای دستورالعمل‌ها، به پیکربندی اپراتور مراجعه کنید.

ساختن

روش دریافت شماره سریال سخت‌افزار، در صورت وجود: getSerial

مدیر گزارش باگر

روشی برای شروع گزارش اشکال اتصال، که نسخه‌ای تخصصی از گزارش اشکال است که فقط شامل اطلاعاتی برای اشکال‌زدایی مشکلات مربوط به اتصال است: startConnectivityBugreport

مدیر آمار شبکه

مدیر ImsMmTel

مدیر ImsRcs

مدیر تأمین

مدیر اجرایی

روش فعال کردن اشتراک داده شده: switchToSubscription

سرویس پیام‌رسان حامل

سرویسی که هنگام ارسال یا دریافت پیامک و MMS جدید، تماس‌هایی را از سیستم دریافت می‌کند. برای گسترش این کلاس، سرویس را در فایل مانیفست خود با مجوز android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE تعریف کنید و یک فیلتر intent را با اکشن #SERVICE_INTERFACE در آن قرار دهید. متدها عبارتند از:

  • روش فیلتر کردن پیامک‌های ورودی: onFilterSms
  • روش رهگیری پیامک‌های متنی ارسالی از دستگاه: onSendTextSms
  • روش رهگیری پیامک‌های دودویی ارسالی از دستگاه: onSendDataSms
  • روش رهگیری پیامک‌های طولانی ارسالی از دستگاه: onSendMultipartTextSms
  • روش رهگیری پیام‌های MMS ارسالی از دستگاه: onSendMms
  • روش دانلود پیام‌های MMS دریافتی: onDownloadMms

خدمات حمل و نقل

سرویسی که قابلیت‌های خاص حامل را در اختیار سیستم قرار می‌دهد. برای گسترش این کلاس، سرویس را در فایل مانیفست برنامه با مجوز android.Manifest.permission#BIND_CARRIER_SERVICES اعلان کنید و یک فیلتر intent با اکشن CARRIER_SERVICE_INTERFACE اضافه کنید. اگر سرویس دارای اتصال طولانی مدت است، android.service.carrier.LONG_LIVED_BINDING را در متادیتای سرویس روی true تنظیم کنید.

این پلتفرم، CarrierService با پرچم‌های ویژه‌ای متصل می‌کند تا به فرآیند سرویس حامل اجازه دهد در یک سطل آماده به کار ویژه برنامه اجرا شود. این امر برنامه سرویس حامل را از محدودیت عدم فعالیت برنامه معاف می‌کند و احتمال زنده ماندن آن را در هنگام کمبود حافظه دستگاه افزایش می‌دهد. با این حال، اگر برنامه سرویس حامل به هر دلیلی از کار بیفتد، تمام امتیازات فوق را تا زمان راه‌اندازی مجدد برنامه و برقراری مجدد اتصال از دست می‌دهد. بنابراین، پایدار نگه داشتن برنامه سرویس حامل بسیار مهم است.

متدهای موجود در CarrierService عبارتند از:

  • برای لغو و تنظیم پیکربندی‌های خاص اپراتور: onLoadConfig
  • برای اطلاع‌رسانی به سیستم در مورد تغییر عمدی شبکه اپراتور توسط برنامه اپراتور: notifyCarrierNetworkChange

ارائه دهنده تلفن

رابط‌های برنامه‌نویسی کاربردی (API) ارائه‌دهنده محتوا برای اعمال تغییرات (درج، حذف، به‌روزرسانی، پرس‌وجو) در پایگاه داده تلفن. فیلدهای مقادیر در Telephony.Carriers تعریف شده‌اند؛ برای جزئیات بیشتر، به مرجع کلاس Telephony مراجعه کنید.

پیشنهاد شبکه وای‌فای

هنگام ساخت یک شیء WifiNetworkSuggestion ، از روش‌های زیر برای تنظیم شناسه اشتراک یا گروه اشتراک استفاده کنید:

پلتفرم اندروید

در یک UICC شناسایی‌شده، پلتفرم اشیاء UICC داخلی را می‌سازد که شامل قوانین امتیاز حامل به عنوان بخشی از UICC هستند. UiccCarrierPrivilegeRules.java قوانین را بارگذاری می‌کند، آنها را از کارت UICC تجزیه می‌کند و در حافظه ذخیره می‌کند. هنگامی که بررسی امتیاز مورد نیاز باشد، UiccCarrierPrivilegeRules گواهی تماس‌گیرنده را یک به یک با قوانین خود مقایسه می‌کند. اگر UICC حذف شود، قوانین به همراه شیء UICC از بین می‌روند.

اعتبارسنجی

برای اعتبارسنجی پیاده‌سازی از طریق مجموعه تست سازگاری (CTS) با استفاده از CtsCarrierApiTestCases.apk ، باید یک UICC توسعه‌دهنده با قوانین UICC صحیح یا پشتیبانی ARF داشته باشید. از فروشنده سیم‌کارت مورد نظر خود بخواهید که یک UICC توسعه‌دهنده با ARF مناسب، همانطور که در این بخش توضیح داده شده است، آماده کند و از آن UICC برای اجرای تست‌ها استفاده کند. UICC برای قبولی در تست‌های CTS نیازی به سرویس تلفن همراه فعال ندارد.

UICC را آماده کنید

برای اندروید ۱۱ و پایین‌تر، CtsCarrierApiTestCases.apk توسط aosp-testkey امضا شده است، با مقدار هش 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

با شروع از اندروید ۱۲، 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 .

برای اجرای تست‌های API اپراتور CTS در اندروید ۱۲، دستگاه باید از سیم‌کارتی با امتیازات اپراتور CTS استفاده کند که الزامات مشخص‌شده در آخرین نسخه مشخصات تست GSMA TS.48 شخص ثالث را برآورده کند.

از همین سیم‌کارت می‌توان برای نسخه‌های قبل از اندروید ۱۲ نیز استفاده کرد.

مشخصات سیم کارت CTS را تغییر دهید

  1. اضافه کنید: امتیازات حامل CTS در برنامه‌ی اصلیِ قانون دسترسی (ARA-M) یا ARF. هر دو امضا باید در قوانین امتیاز حامل رمزگذاری شوند:
    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. ایجاد: فایل‌های ابتدایی ADF USIM (EFs) که در TS.48 وجود ندارند و برای CTS مورد نیاز هستند:
    1. EF_MBDN (6FC7)، اندازه رکورد: 28، شماره رکورد: 4
      • محتوا
        1. شماره ثبت ۱: ۵۶۶F۶۹۶۳۶۵۲۰۴D۶۱۶۹۶CFFFFFFFF۰۶۹۱۵۱۵۵۵۵۵۵۵FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8)، اندازه رکورد: ۱۳، شماره رکورد: ۱
      • محتوا: ۰۰FF…FF
        1. EF_MBI (6FC9)، اندازه رکورد: ۴، شماره رکورد: ۱
      • محتوا: Rec1: 01010101
        1. EF_MWIS (6FCA)، اندازه رکورد: 5، شماره رکورد: 1
      • محتوا: 0000000000
  3. اصلاح: جدول سرویس USIM: فعال کردن سرویس‌های شماره ۴۷ و ۴۸
    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. اصلاح: از رشته نام حامل Android CTS در EF های مربوطه که حاوی این نامگذاری هستند استفاده کنید:
    1. EF_SPN (USIM/6F46)
      • محتوا: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • محتوا: Rec1 430B83413759FE4E934143EA14FF..FF

ساختار پروفایل آزمون را مطابقت دهید

آخرین نسخه از ساختارهای پروفایل تست عمومی زیر را دانلود و تطبیق دهید. این پروفایل‌ها فاقد قانون امتیاز حامل CTS شخصی‌سازی‌شده یا سایر تغییرات ذکر شده در بالا هستند.

اجرای تست‌ها

برای راحتی، CTS از یک توکن دستگاه پشتیبانی می‌کند که تست‌ها را فقط برای اجرا روی دستگاه‌هایی که با همان توکن پیکربندی شده‌اند، محدود می‌کند. تست‌های CTS API اپراتور از توکن دستگاه sim-card-with-certs پشتیبانی می‌کنند. به عنوان مثال، توکن دستگاه زیر تست‌های API اپراتور را فقط برای اجرا روی دستگاه abcd1234 محدود می‌کند:

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

هنگام اجرای تست بدون استفاده از توکن دستگاه، تست روی همه دستگاه‌ها اجرا می‌شود.

سوالات متداول

چگونه می‌توان گواهینامه‌ها را در UICC به‌روزرسانی کرد؟

الف) از مکانیزم به‌روزرسانی OTA کارت موجود استفاده کنید.

آیا UICC می‌تواند با سایر قوانین همزیستی داشته باشد؟

الف) اشکالی ندارد که قوانین امنیتی دیگری در UICC تحت همان AID وجود داشته باشد؛ پلتفرم آنها را به طور خودکار فیلتر می‌کند.

چه اتفاقی می‌افتد وقتی UICC برای برنامه‌ای که به گواهینامه‌های موجود در آن متکی است، حذف شود؟

الف) برنامه امتیازات خود را از دست می‌دهد زیرا قوانین مرتبط با UICC با حذف UICC از بین می‌روند.

آیا محدودیتی در تعداد گواهینامه‌ها در UICC وجود دارد؟

الف) پلتفرم تعداد گواهی‌ها را محدود نمی‌کند؛ اما از آنجا که بررسی خطی است، تعداد زیاد قوانین ممکن است باعث تأخیر در بررسی شود.

آیا محدودیتی در تعداد APIهایی که می‌توانیم با این روش پشتیبانی کنیم وجود دارد؟

الف) خیر، اما ما دامنه‌ی کار را به APIهای مربوط به اپراتور محدود می‌کنیم.

آیا APIهایی وجود دارند که استفاده از این روش را ممنوع کرده‌اند؟ اگر چنین است، چگونه آنها را ملزم به رعایت آنها می‌کنید؟ (یعنی، آیا تست‌هایی برای اعتبارسنجی APIهایی که با این روش پشتیبانی می‌شوند، دارید؟)

الف) به بخش سازگاری رفتاری API در سند تعریف سازگاری اندروید (CDD) مراجعه کنید. ما چند آزمایش CTS داریم تا مطمئن شویم مدل مجوز APIها تغییر نکرده است.

این چطور با قابلیت چند سیم‌کارت کار می‌کند؟

الف) سیم‌کارت پیش‌فرض مشخص‌شده توسط کاربر استفاده می‌شود.

آیا این به هیچ وجه با سایر فناوری‌های دسترسی به خدمات سرور، مثلاً SEEK، تعامل یا همپوشانی دارد؟

الف) به عنوان مثال، SEEK از همان AID موجود در UICC استفاده می‌کند. بنابراین قوانین در کنار هم وجود دارند و توسط SEEK یا UiccCarrierPrivileges فیلتر می‌شوند.

چه زمانی برای بررسی امتیازات اپراتور مناسب است؟

الف) بعد از اینکه وضعیت سیم‌کارت بارگذاری شد، پخش می‌شود.

آیا تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند بخشی از APIهای اپراتور را غیرفعال کنند؟

الف) خیر. ما معتقدیم که API های فعلی حداقل مجموعه هستند و قصد داریم در آینده از ماسک بیتی برای کنترل دقیق‌تر جزئیات استفاده کنیم.

آیا setOperatorBrandOverride تمام اشکال دیگر رشته‌های نام عملگر را لغو می‌کند؟ برای مثال، SE13، UICC SPN یا NITZ مبتنی بر شبکه؟

بله، لغو نام اپراتور بالاترین اولویت را دارد. وقتی تنظیم شود، تمام اشکال دیگر رشته‌های نام اپراتور را لغو می‌کند.

فراخوانی متد injectSmsPdu چه کاری انجام می‌دهد؟

الف) این روش پشتیبان‌گیری/بازیابی پیامک‌ها را در فضای ابری تسهیل می‌کند. فراخوانی injectSmsPdu تابع بازیابی را فعال می‌کند.

برای فیلتر کردن پیامک، آیا فراخوانی onFilterSms بر اساس فیلتر کردن پورت UDH پیامک است؟ یا برنامه‌های اپراتور به تمام پیامک‌های دریافتی دسترسی دارند؟

الف) اپراتورها به تمام داده‌های پیامک دسترسی دارند.

به نظر می‌رسد که افزونه‌ی DeviceAppID-REF-DO برای پشتیبانی از ۳۲ بایت با مشخصات فعلی GP (که فقط ۰ یا ۲۰ بایت را مجاز می‌داند) ناسازگار است، پس چرا این تغییر را معرفی می‌کنید؟ آیا SHA-1 برای جلوگیری از تصادم کافی نیست؟ آیا این تغییر را قبلاً به GP پیشنهاد کرده‌اید، زیرا می‌تواند با ARA-M/ARF موجود ناسازگار باشد؟

الف) برای ارائه امنیت پایدار در آینده، این افزونه علاوه بر SHA-1، که در حال حاضر تنها گزینه در استاندارد GP SEAC است، SHA-256 را برای DeviceAppID-REF-DO معرفی می‌کند. ما اکیداً استفاده از SHA-256 را توصیه می‌کنیم.

اگر DeviceAppID برابر با 0 (خالی) باشد، آیا این قانون را برای همه برنامه‌های دستگاه که تحت پوشش یک قانون خاص نیستند، اعمال می‌کنید؟

الف) APIهای اپراتورها نیاز به پر کردن DeviceAppID-REF-DO دارند. خالی بودن آن برای اهداف آزمایشی در نظر گرفته شده و برای استقرارهای عملیاتی توصیه نمی‌شود.

طبق مشخصات شما، PKG-REF-DO که به تنهایی و بدون DeviceAppID-REF-DO استفاده می‌شود، نباید پذیرفته شود. اما همچنان در جدول 6-4 مشخصات به عنوان بسط تعریف REF-DO توصیف شده است. آیا این عمدی است؟ وقتی فقط PKG-REF-DO در REF-DO استفاده می‌شود، کد چگونه رفتار می‌کند؟

الف) گزینه‌ی داشتن PKG-REF-DO به عنوان یک آیتم تک مقداری در REF-DO در آخرین نسخه حذف شده است. PKG-REF-DO فقط باید در ترکیب با DeviceAppID-REF-DO رخ دهد.

ما فرض می‌کنیم که می‌توانیم به همه مجوزهای مبتنی بر حامل دسترسی بدهیم یا کنترل دقیق‌تری داشته باشیم. اگر چنین است، چه چیزی نگاشت بین ماسک بیتی و مجوزهای واقعی را تعریف می‌کند؟ یک مجوز برای هر کلاس؟ یک مجوز برای هر متد؟ آیا در درازمدت ۶۴ مجوز جداگانه کافی است؟

الف) این موضوع برای آینده محفوظ است و ما از پیشنهادات استقبال می‌کنیم.

آیا می‌توانید DeviceAppID به طور خاص برای اندروید تعریف کنید؟ این مقدار هش SHA-1 (20 بایت) گواهی ناشر است که برای امضای برنامه مورد نظر استفاده می‌شود، بنابراین آیا نام نباید این هدف را منعکس کند؟ (این نام می‌تواند برای بسیاری از خوانندگان گیج‌کننده باشد زیرا این قانون برای همه برنامه‌های امضا شده با همان گواهی ناشر قابل اجرا است.)

الف) گواهی‌های ذخیره‌سازی DeviceAppID توسط مشخصات موجود پشتیبانی می‌شوند. ما سعی کردیم تغییرات مشخصات را به حداقل برسانیم تا موانع پذیرش کاهش یابد. برای جزئیات بیشتر، به قوانین UICC مراجعه کنید.

،

اندروید ۵.۱ مکانیزمی را برای اعطای امتیازات ویژه به APIهای مربوط به دارندگان برنامه‌های کارت مدار مجتمع جهانی (UICC) معرفی کرد. پلتفرم اندروید گواهی‌های ذخیره شده در UICC را بارگذاری می‌کند و به برنامه‌هایی که توسط این گواهی‌ها امضا شده‌اند، اجازه می‌دهد تا با تعداد انگشت‌شماری از APIهای ویژه تماس برقرار کنند.

اندروید ۷.۰ این ویژگی را برای پشتیبانی از سایر منابع ذخیره‌سازی برای قوانین امتیاز اپراتور UICC گسترش داده است و تعداد اپراتورهایی را که می‌توانند از APIها استفاده کنند، به طرز چشمگیری افزایش داده است. برای مرجع API، به CarrierConfigManager مراجعه کنید؛ برای دستورالعمل‌ها، به Carrier Configuration مراجعه کنید.

اپراتورها کنترل کامل UICC را دارند، بنابراین این مکانیسم روشی امن و انعطاف‌پذیر برای مدیریت برنامه‌های اپراتور شبکه تلفن همراه (MNO) که در کانال‌های توزیع عمومی برنامه (مانند Google Play) میزبانی می‌شوند، فراهم می‌کند، در حالی که امتیازات ویژه را در دستگاه‌ها حفظ می‌کند و نیازی به امضای برنامه‌ها با گواهی پلتفرم هر دستگاه یا نصب اولیه به عنوان یک برنامه سیستمی ندارد.

قوانین مربوط به UICC

ذخیره‌سازی در UICC با مشخصات GlobalPlatform Secure Element Access Control سازگار است. شناسه برنامه (AID) روی کارت A00000015141434C00 است و از دستور استاندارد GET DATA برای دریافت قوانین ذخیره شده روی کارت استفاده می‌شود. می‌توانید این قوانین را از طریق به‌روزرسانی‌های کارت از طریق بی‌سیم (OTA) به‌روزرسانی کنید.

سلسله مراتب داده

قوانین UICC از سلسله مراتب داده زیر استفاده می‌کنند (ترکیب دو کاراکتری حرف و عدد داخل پرانتز، برچسب شیء است). هر قانون 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، حداکثر طول ۱۲۷ بایت.
  • AR-DO ( E3 ) گسترش یافته است تا PERM-AR-DO ( DB ) را نیز شامل شود، که یک ماسک بیتی ۸ بایتی است که ۶۴ مجوز جداگانه را نشان می‌دهد.

اگر PKG-REF-DO وجود نداشته باشد، به هر برنامه‌ای که توسط گواهی امضا شده باشد، دسترسی داده می‌شود؛ در غیر این صورت، هم گواهی و هم نام بسته باید مطابقت داشته باشند.

مثال قانون

نام برنامه com.google.android.apps.myapp است و گواهی SHA-1 در رشته هگز به صورت زیر است:

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

قانون UICC در رشته هگز به صورت زیر است:

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

پشتیبانی از فایل قوانین دسترسی

اندروید ۷.۰ پشتیبانی از خواندن قوانین امتیاز حامل از فایل قانون دسترسی (ARF) را اضافه کرده است.

پلتفرم اندروید ابتدا تلاش می‌کند تا برنامه‌ی قواعد دسترسی (ARA) با شناسه‌ی A00000015141434C00 را انتخاب کند. اگر AID را در UICC پیدا نکند، با انتخاب PKCS15 AID A000000063504B43532D3135 به ARF برمی‌گردد. سپس اندروید فایل قواعد کنترل دسترسی (ACRF) را در 0x4300 می‌خواند و به دنبال ورودی‌هایی با شناسه‌ی AID FFFFFFFFFFFF می‌گردد. ورودی‌هایی با AIDهای مختلف نادیده گرفته می‌شوند، بنابراین قوانین مربوط به سایر موارد استفاده می‌توانند همزمان وجود داشته باشند.

مثال محتوای 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 آدرس ACCF است که شامل هش گواهی 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . برنامه‌هایی که توسط این گواهی امضا شده‌اند، دارای امتیازات اپراتور هستند.

API های فعال شده

اندروید از API های زیر پشتیبانی می کند.

مدیر تلفن

تماس تلفنی

TelephonyCallback رابط‌هایی با یک متد callback دارد که هنگام تغییر وضعیت‌های ثبت‌شده، به برنامه‌ی فراخوانی‌کننده اطلاع می‌دهد:

مدیر اشتراک

مدیر پیامک

  • روشی که به تماس‌گیرنده اجازه می‌دهد پیامک‌های دریافتی جدید ایجاد کند: injectSmsPdu .
  • روشی برای ارسال پیامک متنی بدون نوشتن در ارائه دهنده پیامک: sendTextMessageWithoutPersisting

مدیر پیکربندی حامل

  • روش اعلام تغییر پیکربندی: notifyConfigChangedForSubId .
  • روش دریافت پیکربندی اپراتور برای اشتراک پیش‌فرض: getConfig
  • روش دریافت پیکربندی اپراتور برای اشتراک مشخص شده: getConfigForSubId

برای دستورالعمل‌ها، به پیکربندی اپراتور مراجعه کنید.

ساختن

روش دریافت شماره سریال سخت‌افزار، در صورت وجود: getSerial

مدیر گزارش باگر

روشی برای شروع گزارش اشکال اتصال، که نسخه‌ای تخصصی از گزارش اشکال است که فقط شامل اطلاعاتی برای اشکال‌زدایی مشکلات مربوط به اتصال است: startConnectivityBugreport

مدیر آمار شبکه

مدیر ImsMmTel

مدیر ImsRcs

مدیر تأمین

مدیر اجرایی

روش فعال کردن اشتراک داده شده: switchToSubscription

سرویس پیام‌رسان حامل

سرویسی که هنگام ارسال یا دریافت پیامک و MMS جدید، تماس‌هایی را از سیستم دریافت می‌کند. برای گسترش این کلاس، سرویس را در فایل مانیفست خود با مجوز android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE تعریف کنید و یک فیلتر intent را با اکشن #SERVICE_INTERFACE در آن قرار دهید. متدها عبارتند از:

  • روش فیلتر کردن پیامک‌های ورودی: onFilterSms
  • روش رهگیری پیامک‌های متنی ارسالی از دستگاه: onSendTextSms
  • روش رهگیری پیامک‌های دودویی ارسالی از دستگاه: onSendDataSms
  • روش رهگیری پیامک‌های طولانی ارسالی از دستگاه: onSendMultipartTextSms
  • روش رهگیری پیام‌های MMS ارسالی از دستگاه: onSendMms
  • روش دانلود پیام‌های MMS دریافتی: onDownloadMms

خدمات حمل و نقل

سرویسی که قابلیت‌های خاص حامل را در اختیار سیستم قرار می‌دهد. برای گسترش این کلاس، سرویس را در فایل مانیفست برنامه با مجوز android.Manifest.permission#BIND_CARRIER_SERVICES اعلان کنید و یک فیلتر intent با اکشن CARRIER_SERVICE_INTERFACE اضافه کنید. اگر سرویس دارای اتصال طولانی مدت است، android.service.carrier.LONG_LIVED_BINDING را در متادیتای سرویس روی true تنظیم کنید.

این پلتفرم، CarrierService با پرچم‌های ویژه‌ای متصل می‌کند تا به فرآیند سرویس حامل اجازه دهد در یک سطل آماده به کار ویژه برنامه اجرا شود. این امر برنامه سرویس حامل را از محدودیت عدم فعالیت برنامه معاف می‌کند و احتمال زنده ماندن آن را در هنگام کمبود حافظه دستگاه افزایش می‌دهد. با این حال، اگر برنامه سرویس حامل به هر دلیلی از کار بیفتد، تمام امتیازات فوق را تا زمان راه‌اندازی مجدد برنامه و برقراری مجدد اتصال از دست می‌دهد. بنابراین، پایدار نگه داشتن برنامه سرویس حامل بسیار مهم است.

متدهای موجود در CarrierService عبارتند از:

  • برای لغو و تنظیم پیکربندی‌های خاص اپراتور: onLoadConfig
  • برای اطلاع‌رسانی به سیستم در مورد تغییر عمدی شبکه اپراتور توسط برنامه اپراتور: notifyCarrierNetworkChange

ارائه دهنده تلفن

رابط‌های برنامه‌نویسی کاربردی (API) ارائه‌دهنده محتوا برای اعمال تغییرات (درج، حذف، به‌روزرسانی، پرس‌وجو) در پایگاه داده تلفن. فیلدهای مقادیر در Telephony.Carriers تعریف شده‌اند؛ برای جزئیات بیشتر، به مرجع کلاس Telephony مراجعه کنید.

پیشنهاد شبکه وای‌فای

هنگام ساخت یک شیء WifiNetworkSuggestion ، از روش‌های زیر برای تنظیم شناسه اشتراک یا گروه اشتراک استفاده کنید:

پلتفرم اندروید

در یک UICC شناسایی‌شده، پلتفرم اشیاء UICC داخلی را می‌سازد که شامل قوانین امتیاز حامل به عنوان بخشی از UICC هستند. UiccCarrierPrivilegeRules.java قوانین را بارگذاری می‌کند، آنها را از کارت UICC تجزیه می‌کند و در حافظه ذخیره می‌کند. هنگامی که بررسی امتیاز مورد نیاز باشد، UiccCarrierPrivilegeRules گواهی تماس‌گیرنده را یک به یک با قوانین خود مقایسه می‌کند. اگر UICC حذف شود، قوانین به همراه شیء UICC از بین می‌روند.

اعتبارسنجی

برای اعتبارسنجی پیاده‌سازی از طریق مجموعه تست سازگاری (CTS) با استفاده از CtsCarrierApiTestCases.apk ، باید یک UICC توسعه‌دهنده با قوانین UICC صحیح یا پشتیبانی ARF داشته باشید. از فروشنده سیم‌کارت مورد نظر خود بخواهید که یک UICC توسعه‌دهنده با ARF مناسب، همانطور که در این بخش توضیح داده شده است، آماده کند و از آن UICC برای اجرای تست‌ها استفاده کند. UICC برای قبولی در تست‌های CTS نیازی به سرویس تلفن همراه فعال ندارد.

UICC را آماده کنید

For Android 11 and lower, CtsCarrierApiTestCases.apk is signed by aosp-testkey , with hash value 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Starting in Android 12, CtsCarrierApiTestCases.apk is signed by cts-uicc-2021-testkey , hash value 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 .

To run CTS carrier API tests in Android 12, the device needs to use a SIM with CTS carrier privileges meeting the requirements specified in the latest version of the third-party GSMA TS.48 Test Profile specification.

The same SIM can also be used for versions prior to Android 12.

Modify the CTS SIM profile

  1. Add: CTS carrier privileges in access rule app master (ARA-M) or ARF. Both signatures must be encoded in the carrier privilege rules:
    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. Create: ADF USIM elementary files (EFs) not present in TS.48 and needed for CTS:
    1. EF_MBDN (6FC7), record size: 28, record number: 4
      • محتوا
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), record size:13, record number: 1
      • Content: 00FF…FF
        1. EF_MBI (6FC9), record size: 4, record number: 1
      • Content: Rec1: 01010101
        1. EF_MWIS (6FCA), record size: 5, record number: 1
      • Content: 0000000000
  3. Modify: USIM service table: Enable services n°47, n°48
    1. EF_UST (6F38)
      • Content: 9EFFBF1DFFFE0083410310010400406E01
  4. Modify: DF-5GS and DF-SAIP files
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Content: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Content: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Content: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Content: A0020000FF…FF
  5. Modify: Use the carrier name string Android CTS in respective EFs containing this designation:
    1. EF_SPN (USIM/6F46)
      • Content: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Content: Rec1 430B83413759FE4E934143EA14FF..FF

Match the test profile structure

Download and match the latest version of the following generic test profile structures. These profiles won't have the CTS Carrier Privilege rule personalized or other modifications listed above.

اجرای تست‌ها

For convenience, CTS supports a device token that restricts tests to run only on devices configured with the same token. Carrier API CTS tests support the device token sim-card-with-certs . For example, the following device token restricts carrier API tests to run only on device abcd1234 :

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

When running a test without using a device token, the test runs on all devices.

سوالات متداول

How can certificates be updated on the UICC?

A: Use the existing card OTA update mechanism.

Can UICC coexist with other rules?

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

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

A: The app loses 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 the number of APIs that we can support with this method?

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

Are there some APIs prohibited from using this method? If so, how do you enforce them? (that is, do you have tests to validate which APIs are supported with this method?)

A: See the API Behavioral Compatibility section of the Android Compatibility Definition Document (CDD). We have some CTS tests to make sure that the permission model of the APIs isn't changed.

How does this work with the multi-SIM feature?

A: The default SIM specified by the user is used.

Does this in any way interact or overlap with other SE access technologies, for example, SEEK?

A: As an example, SEEK uses the same AID as on the UICC. So the rules coexist 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 that the 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, or network-based NITZ?

Yes, the operator brand override has the highest priority. When it's set, it overrides ALL other forms of operator name strings.

What does the injectSmsPdu method call do?

A: This method 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 do carrier apps have access to ALL incoming SMS?

A: Carriers have access to all SMS data.

The extension of DeviceAppID-REF-DO to support 32 bytes appears to be incompatible with the current GP spec (which allows 0 or 20 bytes only), so why are you introducing this change? Isn't SHA-1 sufficient to avoid collisions? Have you proposed this change to GP already, as this could be backward 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. We highly recommend using SHA-256.

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

A: Carrier APIs require DeviceAppID-REF-DO be populated. Being empty is intended for test purposes and isn't recommended for operational deployments.

According to your spec, PKG-REF-DO used just by itself, without DeviceAppID-REF-DO , shouldn't be accepted. But it's still described in Table 6-4 of the specification as extending the definition of REF-DO . Is this on purpose? How does the code behave when only PKG-REF-DO is used in 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 occur only in combination with DeviceAppID-REF-DO .

We assume that we can grant access to all carrier-based permissions or have finer-grained control. If so, what defines the mapping between the bit mask and the actual permissions? One permission per class? One permission per method? Are 64 separate permissions enough in the long run?

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

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

A: The DeviceAppID storing certificates is supported by the existing spec. We tried to minimize spec changes to lower the barrier for adoption. For details, see Rules on UICC .