Open Mobile API (OMAPI) הוא ממשק API סטנדרטי שמשמש לתקשורת עם Secure Element במכשיר. לפני Android 13, רק לאפליקציות ולמודולים של מסגרת הייתה גישה לממשק הזה. על ידי המרה לממשק יציב של ספק, מודולי HAL יכולים גם לתקשר עם רכיבי האבטחה באמצעות שירות OMAPI.
נוספה רשומת גישה ל-OMAPI למודולי HAL בלי לשנות אף API בממשק הקיים הנוכחי. אין צורך לבצע שינויים במודולים קיימים של אפליקציות ומסגרות שמשתמשים בממשק הזה.
במסגרת תוכנית Android Ready SE, אנחנו מאפשרים להשתמש בתכונות אבטחה מרכזיות של Android כמו Keymaster, KeyMint, Identity Credentials ו-Remote Key Provisioning ב-Secure Elements. כדי להפעיל את התכונות האלה, רכיבי HAL (רכיבי ספק) של התכונות האלה צריכים לתקשר עם הרכיב המאובטח באמצעות הממשק היציב של ספק OMAPI.
ארכיטקטורת עיצוב

איור 1. תכנון הארכיטקטורה.
יצרני ציוד מקורי שמשלבים רכיב מאובטח ותכונות של Android Ready SE במכשירים שלהם צריכים להפעיל את הממשק הזה, כי הוא מושבת כברירת מחדל. לפני העדכון הזה, כללי הגישה לרכיב המאובטח הוגדרו לפי שם החבילה או לפי הגיבובים של החתימה שלה (הפניה לאפליקציה במכשיר) ומזהה ה-AID (הפניה לאפליקציה ב-SE). למודולים של HAL לא היו מזהים ייחודיים כמו שמות חבילות או אישורי חתימה. ב-Android מגרסה 13 ואילך, שירות הספק היציב של OMAPI מאפשר למודולי HAL לגשת לרכיב המאובטח. ספקי SE יכולים להגדיר מזהה ייחודי UUID של 16 בייט. כדי להחיל את כלל הגישה הזה על מודולי HAL, ספקי SE נדרשים למפות את מזהה ה-UUID הייחודי הזה בן 16 הבייטים למזהה UID של מודול HAL בקובץ ה-XML של הגדרת מיפוי מזהה ה-UUID של הספק.
שירות OMAPI Vendor Stable Service מוסיף ל-UUID את הערך FF אם צריך כדי להגיע ל-20 בייט, כמו שמוסבר בקטע 6.1, DeviceAppID-REF-DO page: 66. השירות גם מגדיר כללי גישה ברכיבים מאובטחים באמצעות ה-UUID הזה של 20 בייט כהפניה לאפליקציה במכשיר.
שם הקובץ של מיפוי ה-UUID של הספק מורכב מהקידומת המוגדרת מראש hal_uuid_map_, ומתווסף לו הערך של מאפיין המערכת ro.boot.product.hardware.sku.
hal_uuid_map_value_of_ro.boot.product.hardware.sku.xml
השירות OMAPI Vendor Stable מחפש את הקובץ הזה בתיקיות /odm/etc/, /vendor/etc/ ו-/etc/. כאן אפשר לקרוא תיאור מפורט של קובץ ההגדרות של מיפוי ה-UUID של הספק.
הטמעה
כדי להפעיל את התכונה OMAPI Vendor Stable Service בגרסת יעד, צריך לבצע את השינויים הבאים.
SecureElement
SecureElement
מפעילים את דגל השירות
secure_element_vintf_enabled באמצעות שכבת-על של משאבים בתיקיות ספציפיות למכשיר.
<bool name="secure_element_vintf_enabled">true</bool>
מגדירים את ה-XML של מיפוי ה-UID וה-UUID לשירות.
<ref_do>
<uuid_ref_do>
<uids>
<uid>0</uid>
</uids>
<uuid>9f36407ead0639fc966f14dde7970f68</uuid>
</uuid_ref_do>
<uuid_ref_do>
<uids>
<uid>1096</uid>
<uid>1097</uid>
</uids>
<uuid>a9b7ba70783b317e9998dc4dd82eb3c5</uuid>
</uuid_ref_do>
</ref_do>הקצאת הרשאות של רכיב מאובטח (SE) לשירות HAL באמצעות מזהי UUID כהפניות לאפליקציות במכשיר. מוסיפים רשומת מיפוי בהגדרות המיפוי, שבה אפשר למפות את ה-UUID הזה למזהה מודול HAL. בעזרת המיפוי הזה, ספקים מאפשרים למודולי HAL לגשת לרכיב מאובטח. אפשר להשתמש בבדיקות OMAPI VTS כהטמעות לדוגמה כדי להפעיל את שירות OMAPI Vendor Stable במודולי HAL.
עדכון של sepolicy במודול HAL: מוסיפים כלל sepolicy למודול HAL כדי לאפשר לדומיין שלו לגשת לשירות היציב של ספק OMAPI.
allow hal_module_label secure_element_service:service_manager find
התחברות לשירות יציב של ספק OMAPI: ממודולי HAL משתמשים בתווית השירות של ספק OMAPI
android.se.omapi.ISecureElementService/defaultandroid.se.omapi.ISecureElementService/default
כדי להתחבר לשירות.
אימות
כדי לוודא שהטמעתם בהצלחה את שירות הספק היציב של OMAPI, מריצים את הבדיקות של OMAPI VTS.
run vts -m VtsHalOmapiSeServiceV1_TargetTest
run vts -m VtsHalOmapiSeAccessControlTestCases