از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
Authentication
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
اندروید دارای مفهوم احراز هویت کاربر است که برای باز کردن قفل دستگاه و دسترسی به کلیدهای رمزنگاری استفاده می شود. این شامل اجزای زیر است:
- ذخیره سازی کلید رمزنگاری و ارائه دهنده خدمات. کلیدهای رمزنگاری را ذخیره می کند و روال های رمزنگاری استاندارد را در بالای آن کلیدها ارائه می دهد. Android از Keystore و KeyMint (قبلاً Keymaster) با پشتوانه سخت‌افزاری برای خدمات رمزنگاری پشتیبانی می‌کند، از جمله رمزنگاری سخت‌افزاری برای ذخیره‌سازی کلید که ممکن است شامل یک محیط اجرای مطمئن (TEE) یا Secure Element (SE) مانند StrongBox باشد.
- احراز هویت کاربر حضور کاربر و/یا احراز هویت موفق را تأیید کنید. اندروید از Gatekeeper برای احراز هویت پین/الگو/رمز عبور و اثر انگشت برای احراز هویت با اثر انگشت پشتیبانی می‌کند. دستگاه‌هایی که با Android 9 و بالاتر عرضه می‌شوند می‌توانند از
BiometricPrompt به عنوان یک نقطه ادغام برای اثر انگشت و بیومتریک اضافی استفاده کنند. این مولفه ها وضعیت احراز هویت خود را از طریق یک کانال احراز هویت شده با سرویس keystore ارتباط می دهند. ( سیستم Android Keystore در سطح چارچوب نیز توسط سرویس Keystore پشتیبانی می شود.)
هر یک از این مؤلفه‌ها مختص فروشنده است، اما پیاده‌سازی فروشنده برای برآوردن مشخصات رابط لایه انتزاعی سخت‌افزار (HAL) و گذراندن آزمایش‌های مجموعه تست فروشنده (VTS) مربوطه مورد نیاز است.
پیاده سازی های فروشنده نیز معمولاً به دو بخش تقسیم می شوند که توسط یک مکانیسم ارتباطی خاص فروشنده به هم متصل می شوند:
- یک سرویس HAL به عنوان یک فرآیند سیستم اندروید اجرا می شود و درخواست های Binder را از سیستم اندروید دریافت می کند.
- یک برنامه قابل اعتماد (TA) در محیط امن اجرا می شود و عملیات ایمن واقعی را انجام می دهد.
ثبت نام
در اولین راه‌اندازی دستگاه پس از بازنشانی کارخانه، همه احراز هویت‌کنندگان برای دریافت ثبت‌نام اعتبار از کاربر آماده می‌شوند. کاربر باید ابتدا یک پین، الگو یا رمز عبور را در Gatekeeper (یا Weaver، در صورت وجود) ثبت کند. این ثبت‌نام اولیه یک شناسه امن کاربر 64 بیتی (SID) به‌طور تصادفی ایجاد می‌کند که به عنوان یک شناسه برای کاربر و به عنوان یک نشانه الزام‌آور برای مواد رمزنگاری کاربر عمل می‌کند. این SID کاربر از نظر رمزنگاری به رمز عبور کاربر متصل است. احراز هویت موفق Gatekeeper منجر به AuthToken هایی می شود که حاوی SID کاربر برای آن رمز عبور است.
کاربری که می خواهد اعتبار موجود را تغییر دهد باید آن اعتبار را ارائه دهد. اگر اعتبار موجود با موفقیت تأیید شود، SID کاربر مرتبط با اعتبار موجود به اعتبار جدید منتقل می‌شود و کاربر را قادر می‌سازد تا پس از تغییر اعتبار به کلیدها دسترسی داشته باشد.
در برخی شرایط، یک سرپرست دستگاه می‌تواند یک ثبت نام غیرقابل اعتماد برای ثبت یک اعتبار جدید بدون ارائه اعتبار موجود انجام دهد. این به کاربر امکان دسترسی به دستگاه را می دهد، اما کلیدهای ایجاد شده تحت SID کاربر قدیمی برای همیشه گم می شوند.
احراز هویت
این بخش یک جریان احراز هویت معمولی را توصیف می کند که شامل تعاملات بین چندین مؤلفه هم در Android و هم در محیط امن است. توجه داشته باشید که همه اجزای امن یک کلید مخفی HMAC (در هر بوت) مشترک دارند که از آن برای احراز هویت پیام های یکدیگر استفاده می کنند.
پس از اینکه کاربر یک اعتبارنامه را تنظیم کرد و یک SID کاربر به او اختصاص داد، می‌تواند احراز هویت را شروع کند، که زمانی شروع می‌شود که کاربر یک پین، الگو، رمز عبور، اثر انگشت یا سایر بیومتریک‌های قوی ارائه کند. 
شکل 1. جریان احراز هویت
- یک کاربر یک روش احراز هویت را ارائه می دهد و سرویس مرتبط درخواستی را به سرویس HAL می دهد.
- برای پین، الگو یا رمز عبور،
LockSettingsService درخواستی از gatekeeperd می‌کند. - جریان‌های احراز هویت مبتنی بر بیومتریک به نسخه Android بستگی دارد. در دستگاه‌هایی که Android نسخه 8.x و پایین‌تر دارند،
FingerprintService درخواست fingerprintd می‌کند. در دستگاه‌های دارای Android 9 و بالاتر، BiometricPrompt با استفاده از کلاس Biometric Manager مناسب، مانند FingerprintManager یا FaceManager ، از دیمون بیومتریک مناسب (به عنوان مثال، fingerprintd برای اثر انگشت یا faced برای چهره) درخواست می‌کند. صرف نظر از نسخه، احراز هویت بیومتریک به صورت ناهمزمان پس از ارسال درخواست انجام می شود.
- سرویس HAL داده ها را به همتای خود TA می فرستد که یک AuthToken تولید می کند:
- برای احراز هویت پین/الگو/رمز عبور،
gatekeeperd پین، الگو یا هش رمز عبور را از طریق سرویس Gatekeeper HAL به Gatekeeper TA در TEE می‌فرستد. اگر احراز هویت در TEE موفقیت آمیز باشد، Gatekeeper TA یک AuthToken حاوی SID کاربر مربوطه (امضا شده با کلید HMAC مشترک) منتشر می کند. - برای احراز هویت اثر انگشت،
fingerprintd به رویدادهای اثر انگشت گوش می‌دهد و داده‌ها را از طریق HAL اثر انگشت به Fingerprint TA در TEE ارسال می‌کند. اگر احراز هویت در TEE موفقیت آمیز باشد، اثر انگشت TA یک AuthToken (که با کلید AuthToken HMAC امضا شده است) منتشر می کند. - برای سایر احراز هویت بیومتریک، شبح بیومتریک مناسب به رویداد بیومتریک گوش می دهد و آن را به سرویس HAL و TA بیومتریک مناسب می فرستد.
- دیمون یک AuthToken امضا شده دریافت می کند و آن را از طریق یک افزونه به رابط Binder سرویس keystore به سرویس keystore ارسال می کند. (
gatekeeperd همچنین هنگام قفل مجدد دستگاه و تغییر رمز دستگاه به سرویس فروشگاه کلید اطلاع می دهد.) - سرویس Keystore AuthTokens را به KeyMint ارسال می کند و با استفاده از کلید مشترک با Gatekeeper و مؤلفه TEE بیومتریک پشتیبانی شده، آنها را تأیید می کند. KeyMint به مهر زمانی در توکن به عنوان آخرین زمان احراز هویت اعتماد می کند و یک تصمیم آزادسازی کلید (برای اجازه دادن به برنامه برای استفاده از کلید) بر روی مهر زمانی است.
جریان احراز هویت نیازی به ارتباط مستقیم بین TAها در محیط امن ندارد: AuthTokenها از TA احراز هویت کننده به سرویس keystore2 در اندروید جریان می یابند که به نوبه خود آنها را به KeyMint TA منتقل می کند. این همچنین به سرویس keystore2 اجازه می‌دهد تا به سرعت درخواست‌هایی را که ممکن است شکست بخورند، رد کند، زیرا از AuthTokenهای موجود در سیستم آگاهی دارد و یک IPC بالقوه پرهزینه را در TEE ذخیره می‌کند.
فرمت AuthToken با مشخصات AIDL در HardwareAuthToken.aidl ارائه شده است.
جریان بوت دستگاه
در هر بوت یک دستگاه، کلید AuthToken HMAC باید تولید شده و با تمام اجزای TEE (Gatekeeper، KeyMint و تراست های بیومتریک پشتیبانی شده) به اشتراک گذاشته شود. بنابراین، برای محافظت بیشتر در برابر حملات مجدد، کلید HMAC باید هر بار که دستگاه راه‌اندازی مجدد می‌شود، به‌طور تصادفی تولید شود.
دو راه متداول وجود دارد که TAها به این کلید HMAC مشترک دسترسی پیدا می کنند:
- قرارداد مخفی مشترک: سرویس
keystore2 یک پروتکل توافقنامه کلید چند طرفه را هنگام راه‌اندازی دستگاه اجرا می‌کند و امکان استخراج امن کلید HMAC را بین آن دسته از TAهای شرکت‌کننده فراهم می‌کند. با این حال، TAهای شرکت کننده باید به یک راز مشترک از قبل به اشتراک گذاشته شده دسترسی داشته باشند. - دسترسی مستقیم: TAهایی که در یک محیط امن قرار دارند می‌توانند از یک مکانیسم ارتباطی داخلی (که وابسته به پلتفرم است) برای به اشتراک گذاشتن کلید HMAC استفاده کنند.
در هر صورت، کلید HMAC هرگز نباید خارج از TEE در دسترس قرار گیرد.
سیستم عامل Trusty که در کنار اندروید اجرا می شود، نمونه ای از TEE است، اما می توان به جای آن از سایر TEE ها استفاده کرد. Trusty از یک سیستم IPC داخلی برای برقراری ارتباط مستقیم بین KeyMint و Gatekeeper یا Trustlet بیومتریک مناسب استفاده می کند. کلید HMAC فقط در KeyMint نگهداری می شود. اثر انگشت و Gatekeeper برای هر بار استفاده، کلید را از KeyMint درخواست می‌کنند و مقدار را ثابت یا کش نکنید.
از آنجایی که برخی از TEE ها فاقد زیرساخت IPC هستند، هیچ ارتباطی بین اپلت ها در TEE رخ نمی دهد. این همچنین به سرویس keystore اجازه می‌دهد تا به سرعت درخواست‌هایی را که احتمالاً شکست می‌خورند رد کند، زیرا از جدول احراز هویت در سیستم اطلاعات دارد و یک IPC بالقوه پرهزینه را در TEE ذخیره می‌کند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
