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

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

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

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

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

فضای ذخیره سازی در UICC با مشخصات کنترل دسترسی عنصر امن GlobalPlatform سازگار است. شناسه برنامه (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، حداکثر طول 127 بایت.
  • AR-DO ( E3 ) برای شامل PERM-AR-DO ( DB ) گسترش یافته است، که یک ماسک بیتی 8 بایتی است که 64 مجوز جداگانه را نشان می دهد.

اگر 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

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

اندروید 7.0 برای خواندن قوانین امتیاز شرکت مخابراتی از فایل قانون دسترسی (ARF) پشتیبانی می‌کند.

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

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

API های فعال

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

مدیر تلفن

تماس تلفنی

TelephonyCallback دارای رابط هایی با روش پاسخ به تماس است تا در صورت تغییر وضعیت های ثبت شده به برنامه تماس مطلع شود:

مدیر اشتراک

اس ام اس منیجر

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

CarrierConfigManager

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

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

BugreportManager

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

NetworkStats Manager

ImsMmTelManager

ImsRcsManager

Provisioning Manager

EuiccManager

روش تغییر به (فعال کردن) اشتراک داده شده: switchToSubscription

Carrier Messaging Service

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

  • روش فیلتر کردن پیامک های ورودی: onFilterSms
  • روش رهگیری پیامک های متنی ارسال شده از دستگاه: onSendTextSms
  • روش رهگیری پیام های SMS باینری ارسال شده از دستگاه: onSendDataSms
  • روش رهگیری پیامک های طولانی ارسال شده از دستگاه: 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 مراجعه کنید

پیشنهاد WifiNetwork

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

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

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

اعتبار سنجی

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

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

برای اندروید 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 .

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

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

مشخصات سیم کارت 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 (EF) در TS.48 وجود ندارد و برای CTS مورد نیاز است:
    1. EF_MBDN (6FC7)، اندازه رکورد: 28، تعداد رکورد: 4
      • محتوا
        1. Rec1: 566F696365204D61696CFFFFFFFFFF06915155555555FF…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: خدمات شماره 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. اصلاح: از رشته نام شرکت مخابراتی Android CTS در EF های مربوطه حاوی این نام استفاده کنید:
    1. EF_SPN (USIM/6F46)
      • مطالب: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • محتوا: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

تست ها را اجرا کنید

برای راحتی، 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 برای برنامه‌ای که به گواهی‌های موجود در آن متکی است حذف شود؟

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

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

A: پلت فرم تعداد گواهی ها را محدود نمی کند. اما از آنجایی که چک خطی است، بسیاری از قوانین ممکن است تاخیری برای چک داشته باشند.

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

پاسخ: نه، اما ما دامنه را به APIهای مرتبط با حامل محدود می کنیم.

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

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

چگونه با ویژگی چند سیم کارت کار می کند؟

A: سیم کارت پیش فرض مشخص شده توسط کاربر استفاده می شود.

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

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

چه زمانی برای بررسی امتیازات شرکت مخابراتی مناسب است؟

A: پس از بارگیری وضعیت سیم کارت پخش می شود.

آیا OEM ها می توانند بخشی از API های حامل را غیرفعال کنند؟

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

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

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

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

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

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

پاسخ: اپراتورها به تمام داده های پیامک دسترسی دارند.

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

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

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

A: 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 رخ دهد.

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

A: این برای آینده محفوظ است و ما از پیشنهادات استقبال می کنیم.

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

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