امتیازات شرکت مخابراتی UICC

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

Android 7.0 این ویژگی را گسترش داد تا از منابع فضای ذخیره‌سازی دیگر برای قوانین امتیاز شرکت مخابراتی UICC پشتیبانی کند، که این امر تعداد شرکت‌های مخابراتی را که می‌توانند از میاناهای برنامه‌سازی کاربردی استفاده کنند به‌طور چشمگیری افزایش می‌دهد. برای مرجع میانای برنامه‌سازی کاربردی، 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 (۲۰ بایت) یا SHA-256 (۳۲ بایت) گواهینامه را ذخیره می‌کند.
    • ‫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

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

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

پلاتفرم Android ابتدا تلاش می‌کند شناسه برنامه (AID) A00000015141434C00 برنامه قانون دسترسی (ARA) را انتخاب کند. اگر AID را در UICC پیدا نکند، با انتخاب PKCS15 AID A000000063504B43532D3135 به ARF برمی‌گردد. سپس Android فایل قوانین کنترل دسترسی (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 است. برنامه‌های امضاشده با این گواهی امتیازهای شرکت مخابراتی دریافت می‌کنند.

میاناهای برنامه‌سازی کاربردی فعال

‫Android از میاناهای برنامه‌سازی کاربردی زیر پشتیبانی می‌کند.

TelephonyManager

TelephonyCallback

‫TelephonyCallback رابط‌هایی با روش بازخوانی برای اعلام تغییر وضعیت‌های ثبت‌شده به برنامه فراخواننده دارد:

SubscriptionManager

SmsManager

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

CarrierConfigManager

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

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

ساخت

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

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

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

CarrierMessagingService

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

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

CarrierService

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

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

روش‌های CarrierService شامل موارد زیر است:

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

ارائه‌دهنده خدمات تلفنی

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

WifiNetworkSuggestion

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

پلاتفرم Android

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

اعتبارسنجی

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

آماده کردن UICC

برای Android نسخه ۱۱ و پایین‌تر، 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.

برای اجرای آزمایش‌های CTS carrier API در Android 12، دستگاه باید از سیم‌کارتی با امتیازات CTS carrier استفاده کند که الزامات مشخص‌شده در جدیدترین نسخه مشخصات شخص ثالث GSMA TS.48 Test Profile با ADM1 ثابت، کلید = 55555555 / 0x3535353535353535 را برآورده کند.

از همین سیم‌کارت می‌توان برای نسخه‌های قبل‌از Android 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. درهم‌سازی۲(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)، اندازه گزارش: ۲۸، تعداد گزارش: ۴ 
      • محتوا
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8)، اندازه گزارش:۱۳، تعداد گزارش: ۱ 
      • محتوا: 00FF…FF
        1. EF_MBI (6FC9)، اندازه سوابق: ۴، تعداد سوابق: ۱
      • محتوا: Rec1: 01010101
        1. EF_MWIS (6FCA)، اندازه گزارش: ۵، تعداد گزارش: ۱
      • محتوا: 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 از یک کد دستگاه پشتیبانی می‌کند که آزمایش‌ها را محدود می‌کند تا فقط روی دستگاه‌هایی که با همان کد پیکربندی شده‌اند اجرا شوند. آزمایش‌های «مجموعه آزمون سازگاری» میانای برنامه‌سازی کاربردی شرکت مخابراتی از کد دستگاه 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 محدود است؟

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

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

پاسخ: نه، اما محدوده را به «میاناهای برنامه‌سازی کاربردی» مرتبط با شرکت مخابراتی محدود می‌کنیم.

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

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

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

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

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

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

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

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

آیا سازندگان اصلی محصول می‌توانند بخشی از میاناهای برنامه‌سازی کاربردی شرکت مخابراتی را غیرفعال کنند؟

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

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

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

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

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

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

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

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

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

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

A: Carrier APIs require DeviceAppID-REF-DO be populated. خالی بودن برای اهداف آزمایشی درنظر گرفته شده است و برای استقرار عملیاتی توصیه نمی‌شود.

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

پاسخ: گزینه داشتن PKG-REF-DO به‌عنوان موردی با مقدار واحد در REF-DO در جدیدترین نسخه برداشته شده است. ‫PKG-REF-DO باید فقط در ترکیب با DeviceAppID-REF-DO رخ دهد.

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

پاسخ: این مورد برای آینده رزرو شده است و از پیشنهادهای شما استقبال می‌کنیم.

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

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