امتیازات اپراتور 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 شخص ثالث را با یک ADM1 ثابت، کلید = 55555555 / 0x3535353535353535 برآورده کند.

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

مشخصات سیم کارت 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 مراجعه کنید.