اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
Authentication
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتضمّن نظام التشغيل Android مفهوم أدوات مصادقة المستخدم التي تُستخدَم لفتح قفل الجهاز ولحصر الوصول إلى مفاتيح التشفير. يتضمّن ذلك المكوّنات التالية:
- مقدّم خدمة ومساحة تخزين لمفاتيح التشفير تخزِّن هذه الفئة مفاتيح التشفير وتوفّر إجراءات تشفير عادية استنادًا إلى هذه المفاتيح.
يتوافق Android مع Keystore المحمي بواسطة الأجهزة وKeyMint (المعروف سابقًا باسم Keymaster) لتقديم خدمات التشفير، بما في ذلك التشفير المحمي بواسطة الأجهزة لتخزين المفاتيح الذي قد يتضمّن بيئة تنفيذ موثوقة (TEE) أو عنصر آمن (SE)، مثل StrongBox.
- أدوات مصادقة المستخدمين: إثبات تواجد المستخدم و/أو إتمام عملية المصادقة بنجاح يتوافق نظام التشغيل Android مع
Gatekeeper للمصادقة باستخدام رقم التعريف الشخصي أو النقش أو كلمة المرور
وبصمة الإصبع للمصادقة باستخدام بصمة الإصبع. يمكن للأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android والإصدارات الأحدث استخدام
BiometricPrompt كنقطة تكامل واحدة
لبصمات الأصابع والمقاييس الحيوية الإضافية. تتواصل هذه المكوّنات مع خدمة تخزين المفاتيح من خلال قناة مصادقة لتحديد حالة المصادقة.
(يتم أيضًا توفير نظام Android Keystore على مستوى إطار العمل من خلال خدمة Keystore).
كل مكوّن من هذه المكوّنات خاص بالمورّد، ولكن يجب أن يتوافق تنفيذ المورّد مع مواصفات واجهة طبقة تجريد الأجهزة (HAL)، وأن يجتاز اختبارات مجموعة اختبارات المورّد (VTS) ذات الصلة.
يتم عادةً تقسيم عمليات التنفيذ الخاصة بالمورّدين إلى جزأين أيضًا، ويربط بينهما آلية تواصل خاصة بالمورّد :
- يتم تشغيل خدمة HAL كعملية لنظام Android، وتتلقّى طلبات Binder من نظام Android.
- يعمل التطبيق الموثوق (TA) في البيئة الآمنة،
وينفّذ العمليات الآمنة الفعلية.
التسجيل
عند إعادة تشغيل الجهاز لأول مرة بعد إعادة ضبطه على الإعدادات الأصلية، يتم إعداد جميع أدوات المصادقة لتلقّي عمليات تسجيل بيانات الاعتماد من المستخدم. يجب أن يسجّل المستخدم في البداية رقم تعريف شخصي أو نقشًا أو كلمة مرور باستخدام Gatekeeper (أو Weaver، إذا كان متاحًا). يؤدي هذا التسجيل الأوّلي إلى إنشاء معرّف آمن للمستخدم عشوائيًا وبطول 64 بت (SID) يعمل كمعرّف للمستخدم ورمز ربط لمواد التشفير الخاصة بالمستخدم. يتم ربط معرّف الأمان الخاص بالمستخدم هذا بشكل مشفّر بكلمة مرور المستخدم، وتؤدي عمليات المصادقة الناجحة على Gatekeeper إلى إنشاء رموز AuthToken تحتوي على معرّف الأمان الخاص بالمستخدم لكلمة المرور هذه.
على المستخدم الذي يريد تغيير بيانات اعتماد حالية تقديم بيانات الاعتماد هذه. في حال إثبات صحة بيانات اعتماد حالية بنجاح، يتم نقل رقم تعريف الأمان (SID) الخاص بالمستخدم والمرتبط ببيانات الاعتماد الحالية إلى بيانات الاعتماد الجديدة، ما يتيح للمستخدم مواصلة الوصول إلى المفاتيح بعد تغيير بيانات الاعتماد.
في بعض الحالات، يمكن لمشرف الجهاز إجراء تسجيل غير موثوق به لتسجيل بيانات اعتماد جديدة بدون تقديم بيانات اعتماد حالية. يتيح ذلك للمستخدم الوصول إلى الجهاز، ولكن يتم فقدان المفاتيح التي تم إنشاؤها ضمن معرّف الأمان القديم للمستخدم بشكل دائم.
المصادقة
يوضّح هذا القسم مسار مصادقة نموذجيًا يتضمّن تفاعلات بين عدة مكوّنات في كل من نظام التشغيل Android وبيئة الأمان. يُرجى العِلم أنّ جميع المكوّنات الآمنة تشترك في مفتاح HMAC سري (لكل عملية تشغيل) تستخدمه للمصادقة على رسائل بعضها البعض.
بعد أن يضبط المستخدم بيانات اعتماد ويتم تعيين معرّف أمان مستخدم له، يمكنه بدء المصادقة، والتي تبدأ عندما يقدّم المستخدم رقم تعريف شخصي أو نقشًا أو كلمة مرور أو بصمة إصبع أو مقياسًا حيويًا قويًا آخر.
الشكل 1. عملية المصادقة
- يقدّم المستخدم طريقة مصادقة وتُرسل الخدمة المرتبطة بها طلبًا إلى خدمة HAL.
- بالنسبة إلى رقم التعريف الشخصي أو النقش أو كلمة المرور، يرسل التطبيق
LockSettingsService
طلبًا إلى gatekeeperd.
- تعتمد إجراءات المصادقة المستندة إلى المقاييس الحيوية على إصدار Android.
على الأجهزة التي تعمل بالإصدار 8.x من نظام التشغيل Android والإصدارات الأقدم، يرسل
FingerprintService طلبًا إلى fingerprintd. أما على الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android والإصدارات الأحدث، فيرسل BiometricPrompt طلبًا إلى برنامج الخدمة المناسب للقياسات الحيوية (على سبيل المثال، fingerprintd لبصمات الأصابع أو faced للتعرّف على الوجه) باستخدام فئة BiometricManager المناسبة، مثل FingerprintManager أو FaceManager. بغض النظر عن الإصدار، تتم المصادقة بالمقاييس الحيوية بشكل غير متزامن بعد إرسال الطلب.
- ترسل خدمة HAL البيانات إلى TA المقابل، الذي ينشئ
AuthToken:
- لإجراء المصادقة باستخدام رقم التعريف الشخصي أو النقش أو كلمة المرور، يرسل
gatekeeperd تجزئة رقم التعريف الشخصي أو النقش أو كلمة المرور إلى Gatekeeper TA في بيئة التنفيذ الموثوقة (TEE) من خلال خدمة Gatekeeper HAL. في حال نجاح المصادقة في بيئة التنفيذ الموثوقة (TEE)،
ستصدر Gatekeeper TA رمز AuthToken يحتوي على معرّف الأمان (SID) الخاص بالمستخدم (موقّع باستخدام مفتاح HMAC المشترك).
- بالنسبة إلى المصادقة ببصمة الإصبع، يستمع
fingerprintd إلى أحداث بصمة الإصبع ويرسل البيانات إلى تطبيق Fingerprint TA في بيئة التنفيذ الموثوقة (TEE) من خلال طبقة تجريد الأجهزة (HAL) الخاصة ببصمة الإصبع. في حال نجاح المصادقة في بيئة التنفيذ الموثوقة (TEE)، ستصدر خدمة Fingerprint TA رمز AuthToken (موقّع باستخدام مفتاح AuthToken HMAC).
- بالنسبة إلى المصادقة الأخرى بالمقاييس الحيوية، تستمع قائمة برامج التشغيل المناسبة للمقاييس الحيوية إلى حدث المقاييس الحيوية وترسله إلى خدمة HAL المناسبة للمقاييس الحيوية وإلى البيئة التنفيذية الموثوقة.
- يتلقّى البرنامج الخفي AuthToken موقّعًا ويُمرّره إلى خدمة تخزين المفاتيح من خلال إضافة إلى واجهة Binder الخاصة بخدمة تخزين المفاتيح.
(يرسل
gatekeeperd أيضًا إشعارًا إلى خدمة تخزين المفاتيح عند إعادة قفل الجهاز وعند تغيير كلمة مرور الجهاز).
- تنقل خدمة Keystore رموز AuthToken إلى KeyMint وتتحقّق منها
باستخدام المفتاح المشترَك مع Gatekeeper ومكوّن TEE المتوافق مع المقاييس الحيوية. تثق KeyMint بالطابع الزمني في الرمز المميز باعتباره آخر وقت للمصادقة، وتستند في قرار إصدار المفتاح (للسماح لأحد التطبيقات باستخدام المفتاح) إلى الطابع الزمني.
لا يتطلّب مسار المصادقة التواصل المباشر بين التطبيقات الموثوقة في البيئة الآمنة، بل تنتقل رموز AuthToken من تطبيق المصادقة الموثوق إلى خدمة keystore2 في Android، والتي بدورها تنقلها إلى تطبيق KeyMint الموثوق.
يسمح ذلك أيضًا لخدمة keystore2 برفض الطلبات التي من المحتمل أن تفشل بسرعة، لأنّها على دراية برموز AuthToken المتوفّرة في النظام، ما يؤدي إلى توفير عملية IPC التي قد تكون مكلفة في TEE.
يتم تحديد تنسيق AuthToken من خلال مواصفات AIDL في
HardwareAuthToken.aidl.
تسلسل خطوات تشغيل الجهاز
في كل مرة يتم فيها تشغيل الجهاز، يجب إنشاء مفتاح HMAC الخاص برمز AuthToken ومشاركته مع جميع مكونات TEE (مثل Gatekeeper وKeyMint وtrustlet المقاييس الحيوية المتوافقة). وبالتالي، لتوفير حماية إضافية ضد هجمات إعادة الإرسال، يجب إنشاء مفتاح HMAC بشكل عشوائي في كل مرة تتم فيها إعادة تشغيل الجهاز.
هناك طريقتان شائعتان يحصل من خلالهما المساعدون التدريسيون على مفتاح HMAC المشترك هذا:
- اتفاقية السر المشترك: تنفّذ خدمة
keystore2 بروتوكول اتفاقية مفتاح متعدد الاتجاهات عند بدء تشغيل الجهاز، ما يتيح اشتقاق مفتاح HMAC بشكل آمن بين التطبيقات الموثوقة المشارِكة.
ومع ذلك، يجب أن يكون لدى وكلاء النقل المشاركين إذن بالوصول إلى مفتاح سري مشترك مسبقًا.
- الوصول المباشر: يمكن للتطبيقات الموثوقة التي تقع ضمن بيئة آمنة واحدة استخدام آلية داخلية للتواصل بين العمليات (تعتمد على النظام الأساسي) لمشاركة مفتاح HMAC.
في كلتا الحالتين، يجب ألا يتم إتاحة مفتاح HMAC خارج بيئة التنفيذ الموثوقة.
نظام التشغيل Trusty،
الذي يعمل بجانب نظام التشغيل Android، هو مثال على بيئة تنفيذ موثوقة، ولكن يمكن استخدام بيئات تنفيذ موثوقة أخرى
بدلاً منه. يستخدم Trusty نظام IPC داخليًا للتواصل مباشرةً بين KeyMint وGatekeeper أو trustlet المناسب للمصادقة البيومترية. يتم الاحتفاظ بمفتاح HMAC في KeyMint فقط، وتطلب خدمتا Fingerprint وGatekeeper المفتاح من KeyMint في كل مرة يتم استخدامه فيها، ولا يتم الاحتفاظ بالقيمة أو تخزينها مؤقتًا.
وبما أنّ بعض بيئات التنفيذ الموثوقة تفتقر إلى بنية أساسية للاتصال بين العمليات، لا يحدث أي اتصال بين التطبيقات المصغّرة في بيئة التنفيذ الموثوقة. ويسمح ذلك أيضًا لخدمة تخزين المفاتيح برفض الطلبات التي من المحتمل أن تفشل بسرعة لأنّها على دراية بجدول المصادقة في النظام، ما يؤدي إلى توفير عملية اتصال بين العمليات (IPC) قد تكون مكلفة في بيئة التنفيذ الموثوقة (TEE).
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Authentication\n\nAndroid has the concept of user authenticators that are used to unlock the\ndevice and to gate access to cryptographic keys. This involves the following\ncomponents:\n\n- **Cryptographic key storage and service provider.** Stores cryptographic keys and provides standard crypto routines on top of those keys. Android supports a [hardware-backed\n Keystore](/docs/security/features/keystore) and KeyMint (previously Keymaster) for cryptographic services, including hardware-backed cryptography for key storage that might include a Trusted Execution Environment (TEE) or Secure Element (SE), such as StrongBox.\n- **User authenticators.** Attest to the user's presence and/or successful authentication. Android supports [Gatekeeper](/docs/security/features/authentication/gatekeeper) for PIN/pattern/password authentication and [Fingerprint](/docs/security/features/authentication/fingerprint-hal) for fingerprint authentication. Devices that ship with Android 9 and higher can use [`BiometricPrompt`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt) as a single integration point for fingerprint and additional biometrics. These components communicate their authentication state with the keystore service through an authenticated channel. (The [Android Keystore system](https://developer.android.com/training/articles/keystore.html) at the framework level is also backed by the keystore service.)\n\nEach of these components is vendor-specific, but the vendor implementation is required to satisfy\na [Hardware Abstraction Layer (HAL)](/docs/core/architecture/hal) interface\nspecification, and to pass the corresponding vendor test suite (VTS) tests.\n\nVendor implementations are typically also divided into two parts, connected\nby a vendor-specific communication mechanism :\n\n- A *HAL service* runs as an Android system process, receiving Binder requests from the Android system.\n- A *trusted application (TA)* runs in the secure environment, performing the actual secure operations.\n\nEnrollment\n----------\n\nOn first boot of the device after a factory reset, all authenticators are\nprepared to receive credential enrollments from the user. A user must initially\nenroll a PIN, pattern, or password with Gatekeeper (or Weaver, if available). This\ninitial enrollment creates a randomly generated, 64-bit user secure identifier\n(SID) that serves as an identifier for the user and as a binding token for the\nuser's cryptographic material. This user SID is cryptographically bound to the\nuser's password; successful authentications to Gatekeeper result in AuthTokens\nthat contain the user SID for that password.\n\nA user who wants to change an existing credential must present that\ncredential. If an existing credential is verified successfully, the user SID\nassociated with the existing credential is transferred to the new credential,\nenabling the user to keep accessing keys after changing a credential.\n\nIn some situations, a device administrator can perform an *untrusted\nenroll* to enroll a new credential without presenting an existing\ncredential. This allows the user to access the device, but keys created under\nthe old user SID are permanently lost.\n\nAuthentication\n--------------\n\nThis section describes a typical authentication flow, which involves\ninteractions between multiple components in both Android and the secure\nenvironment. Note that all secure components share a (per-boot) secret HMAC key\nthat they use to authenticate each other's messages.\n\nAfter a user has set up a credential and been assigned a user SID, they can\nstart authentication, which begins when a user provides a PIN, pattern,\npassword, fingerprint, or other strong biometric.\n\n\n**Figure 1.** Authentication flow\n\n1. A user provides an authentication method and the associated service makes a request to the HAL service.\n - For PIN, pattern, or password, `LockSettingsService` makes a request to `gatekeeperd`.\n - Biometrics-based authentication flows depend on the Android version. On devices running Android 8.x and lower, `FingerprintService` makes a request to `fingerprintd`). On devices running Android 9 and higher, `BiometricPrompt` makes a request to the appropriate biometric daemon (for example, `fingerprintd` for fingerprints or `faced` for face) using the appropriate \u003cvar translate=\"no\"\u003eBiometric\u003c/var\u003e`Manager` class, such as `FingerprintManager` or `FaceManager`. Regardless of version, biometric authentication occurs asynchronously after the request is sent.\n2. The HAL service sends data to its counterpart TA, which generates an AuthToken:\n - For PIN/pattern/password authentication, `gatekeeperd` sends the PIN, pattern, or password hash to the Gatekeeper TA in the TEE, via the Gatekeeper HAL service. If authentication in the TEE is successful, the Gatekeeper TA emits an AuthToken containing the corresponding user SID (signed with the shared HMAC key).\n - For fingerprint authentication, `fingerprintd` listens for fingerprint events and sends the data to the Fingerprint TA in the TEE, via the Fingerprint HAL. If authentication in the TEE is successful, the Fingerprint TA emits an AuthToken (signed with the AuthToken HMAC key).\n - For other biometric authentication, the appropriate biometric daemon listens for the biometric event and sends it to the appropriate biometric HAL service and TA.\n3. The daemon receives a signed AuthToken and passes it to the keystore service through an extension to the keystore service's Binder interface. (`gatekeeperd` also notifies the keystore service when the device is relocked and when the device password changes.)\n4. The Keystore service passes the AuthTokens to KeyMint and verifies them using the key shared with the Gatekeeper and supported biometric TEE component. KeyMint trusts the timestamp in the token as the last authentication time and bases a key release decision (to allow an app to use the key) on the timestamp.\n\nThe authentication flow does not require direct communication between TAs in\nthe secure environment: AuthTokens flow from the authenticator TA to the\n`keystore2` service in Android, which in turn passes them on to the KeyMint TA.\nThis also permits the `keystore2` service to quickly deny requests\nthat are bound to fail, as it has knowledge of the available AuthTokens in the\nsystem, saving a potentially costly IPC into the TEE.\n\nAuthToken format\n----------------\n\nThe format of the AuthToken is given by the AIDL specification in\n[`HardwareAuthToken.aidl`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/security/keymint/aidl/android/hardware/security/keymint/HardwareAuthToken.aidl).\n\nDevice boot flow\n----------------\n\nOn every boot of a device, the AuthToken HMAC key must be generated and\nshared with all TEE components (Gatekeeper, KeyMint, and supported biometrics\ntrustlets). Thus, for added protection against replay attacks, the HMAC key\nmust be randomly generated every time the device reboots.\n\nThere are two common ways that TAs acquire access to this shared HMAC\nkey:\n\n- *Shared secret agreement:* The `keystore2` service performs a multi-way key agreement protocol at device startup, allowing secure derivation of the HMAC key between those TAs that participate. However, participating TAs must have access to a common preshared secret.\n- *Direct access:* TAs that reside within the same secure environment can use an internal interprocess communication mechanism (which is platform-dependent) to share the HMAC key.\n\n\u003cbr /\u003e\n\nIn either case, the HMAC key must **never** be made available\noutside the TEE.\n\nThe [Trusty](/docs/security/features/trusty) operating system,\nwhich runs next to Android, is an example of a TEE, but other TEEs can be used\ninstead. Trusty uses an internal IPC system to communicate directly between\nKeyMint and Gatekeeper or the appropriate biometric trustlet. The HMAC key is\nkept solely in KeyMint; Fingerprint and Gatekeeper request the key from\nKeyMint for each use and don't persist or cache the value.\n\nAs some TEEs lack an IPC infrastructure, no communication occurs between\napplets in the TEE. This also permits the keystore service to quickly deny\nrequests that are bound to fail as it has knowledge of the authentication table\nin the system, saving a potentially costly IPC into the TEE."]]
