امتیازات حامل 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

پشتیبانی از فایل قانون دسترسی (ARF).

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

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

API های فعال

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

مدیر تلفن

اس ام اس منیجر

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

CarrierConfigManager

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

CarrierMessaging Service

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

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

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

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

در یک 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
  1. ایجاد : 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
  2. تغییر: جدول سرویس USIM: خدمات شماره 47، شماره 48 را فعال کنید
    1. EF_UST (6F38)
      • محتوا: 9EFFBF1DFFFE0083410310010400406E01
  3. اصلاح : فایل های DF-5GS و DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • محتوا: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • محتوا: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  4. اصلاح کنید: رشته های نام حامل باید 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 فیلتر می شوند.

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

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

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

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

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

پاسخ: به ورودی SPN در TelephonyManager مراجعه کنید

فراخوانی متد 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 DO استفاده می شود، کد چگونه عمل می کند؟

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

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

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

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

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