این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

جفت‌های کلید سخت‌افزاری را با تأیید کلید تأیید کنید

تأیید کلید به شما اطمینان بیشتری می دهد که کلیدهایی که در برنامه خود استفاده می کنید در فروشگاه کلیدهای سخت افزاری دستگاه ذخیره می شوند. بخش‌های زیر نحوه تأیید ویژگی‌های کلیدهای سخت‌افزاری و نحوه تفسیر داده‌های پسوند گواهی‌های تأیید را شرح می‌دهند.

توجه: قبل از اینکه ویژگی‌های کلیدهای دارای پشتوانه سخت‌افزاری دستگاه را در محیطی در سطح تولید تأیید کنید، مطمئن شوید که دستگاه از تأیید کلید در سطح سخت‌افزار پشتیبانی می‌کند. برای انجام این کار، بررسی کنید که زنجیره گواهی گواهی حاوی یک گواهی ریشه است که با کلید ریشه گواهی Google امضا شده است و عنصر attestationSecurityLevel در ساختار داده توضیحات کلید روی سطح امنیتی TrustedEnvironment یا سطح امنیتی StrongBox تنظیم شده است.

علاوه بر این، تأیید امضاهای موجود در زنجیره گواهی و تأیید اینکه هیچ یک از کلیدهای زنجیره باطل نشده اند با بررسی لیست وضعیت ابطال گواهی مهم است. مگر اینکه همه معتبر باشند و ریشه کلید اصلی گوگل باشد، به گواهی کاملاً اعتماد نکنید.

یک جفت کلید با پشتوانه سخت افزاری را بازیابی و تأیید کنید

در حین تأیید کلید، نام مستعار یک جفت کلید را مشخص می‌کنید و زنجیره گواهی آن را بازیابی می‌کنید، که می‌توانید از آن برای تأیید ویژگی‌های آن جفت کلید استفاده کنید.

اگر دستگاه از تأیید کلید در سطح سخت‌افزار پشتیبانی می‌کند، گواهی ریشه در این زنجیره با استفاده از یک کلید ریشه تأیید که به طور ایمن در فروشگاه کلید دارای پشتوانه سخت‌افزاری دستگاه ارائه شده است، امضا می‌شود.

توجه: در دستگاه‌هایی که دارای گواهی کلید در سطح سخت‌افزار، Android 7.0 (سطح API 24) یا بالاتر، و سرویس‌های Google Play هستند، گواهی ریشه با کلید اصلی گواهی Google امضا می‌شود. بررسی کنید که این گواهی ریشه از جمله مواردی است که در بخش گواهینامه های ریشه فهرست شده است.

برای اجرای گواهی کلید، مراحل زیر را انجام دهید:

از متد getCertificateChain() یک شی KeyStore برای به دست آوردن ارجاع به زنجیره گواهی های X.509 مرتبط با ذخیره کلید سخت افزاری استفاده کنید.
گواهی ها را برای اعتبارسنجی به سرور جداگانه ای که به آن اعتماد دارید ارسال کنید.
احتیاط: فرآیند تأیید اعتبار زیر را در همان دستگاهی که KeyStore دارد تکمیل نکنید. اگر سیستم Android در آن دستگاه به خطر بیفتد، می تواند باعث شود که فرآیند اعتبارسنجی به چیزی غیرقابل اعتماد اعتماد کند.
مرجع تجزیه و تحلیل زنجیره گواهی و کتابخانه اعتبار سنجی X.509 که برای مجموعه ابزار شما مناسب ترین است، دریافت کنید. بررسی کنید که گواهی عمومی ریشه قابل اعتماد است و هر گواهینامه گواهی بعدی را در زنجیره امضا می کند.
وضعیت ابطال هر گواهی را بررسی کنید تا مطمئن شوید که هیچ یک از گواهی ها باطل نشده اند.
به صورت اختیاری، پسوند گواهی اطلاعات ارائه را که فقط در زنجیره های گواهی جدیدتر وجود دارد، بررسی کنید.
مرجعی به کتابخانه تجزیه کننده CBOR که برای مجموعه ابزار شما مناسب است، دریافت کنید. نزدیکترین گواهی را به ریشه که حاوی پسوند گواهی اطلاعات ارائه است، بیابید. از تجزیه کننده برای استخراج داده های پسوند گواهی اطلاعات تهیه از آن گواهی استفاده کنید.
برای جزئیات بیشتر به بخش مربوط به برنامه افزودنی اطلاعات تهیه مراجعه کنید.
مرجعی به کتابخانه تجزیه کننده ASN.1 که برای مجموعه ابزار شما مناسب تر است، دریافت کنید. نزدیکترین گواهی را به ریشه ای که حاوی پسوند گواهی تأیید کلید است، بیابید. اگر پسوند گواهی اطلاعات تامین وجود داشت، پسوند گواهی تایید کلیدی باید در گواهی بلافاصله بعدی باشد. از تجزیه کننده برای استخراج داده های پسوند گواهی گواهینامه کلیدی از آن گواهی استفاده کنید.
احتیاط: تصور نکنید که پسوند گواهی گواهینامه کلید در گواهی برگ زنجیره است. فقط به اولین رخداد افزونه در زنجیره می توان اعتماد کرد. هر نمونه دیگری از برنامه افزودنی توسط سخت افزار ایمن صادر نشده است و ممکن است توسط مهاجمی صادر شده باشد که زنجیره را گسترش می دهد در حالی که سعی می کند گواهی جعلی برای کلیدهای غیرقابل اعتماد ایجاد کند.
نمونه تأیید کلیدی از تجزیه کننده ASN.1 از Bouncy Castle برای استخراج داده های توسعه گواهی گواهی استفاده می کند. می توانید از این نمونه به عنوان مرجعی برای ایجاد تجزیه کننده خود استفاده کنید.
برای جزئیات بیشتر به بخش مربوط به طرح داده های پسوند گواهی کلید مراجعه کنید.
داده های برنامه افزودنی را که در مراحل قبلی بازیابی کرده اید از نظر سازگاری بررسی کنید و با مجموعه مقادیری که انتظار دارید کلید سخت افزاری دارای پشتوانه سخت افزاری باشد، مقایسه کنید.

گواهی های ریشه

قابل اعتماد بودن گواهی به گواهی ریشه زنجیره بستگی دارد. دستگاه‌های اندرویدی که آزمایش‌های لازم برای داشتن مجموعه برنامه‌های Google از جمله Google Play را گذرانده‌اند و با Android 7.0 (سطح API 24) یا بالاتر راه‌اندازی شده‌اند، باید از کلیدهای تأیید امضا شده توسط گواهینامه Google Hardware Attestation Root استفاده کنند. توجه داشته باشید که تا قبل از Android 8.0 (سطح API 26) به تأیید نیازی نبود. کلید عمومی ریشه به شرح زیر است:

گواهینامه های ریشه صادر شده قبلی

اگر گواهی ریشه در زنجیره گواهی که دریافت می‌کنید حاوی این کلید عمومی باشد و هیچ یک از گواهی‌های زنجیره باطل نشده باشد، می‌دانید که:

کلید شما در سخت افزاری است که گوگل معتقد است امن است. و
دارای خواصی است که در گواهینامه ذکر شده است.

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

اگر گواهی ریشه حاوی کلید عمومی در این صفحه نباشد، دو دلیل محتمل وجود دارد:

به احتمال زیاد، دستگاه با نسخه اندروید کمتر از 7.0 راه اندازی شده است و از تایید سخت افزاری پشتیبانی نمی کند. در این مورد، اندروید دارای یک پیاده‌سازی نرم‌افزار گواهی است که همان نوع گواهی گواهی را تولید می‌کند، اما با یک کلید رمزگذاری شده در کد منبع اندروید امضا شده است. از آنجایی که این کلید امضا مخفی نیست، گواهی ممکن است توسط مهاجمی ایجاد شده باشد که تظاهر به ارائه سخت افزار ایمن می کند.
دلیل احتمالی دیگر این است که دستگاه یک دستگاه Google Play نیست. در این صورت، سازنده دستگاه مختار است که ریشه خود را ایجاد کند و هر ادعایی را که دوست دارد در مورد معنای گواهی ارائه دهد. به مستندات سازنده دستگاه مراجعه کنید. توجه داشته باشید که گوگل از هیچ سازنده دستگاهی که این کار را انجام داده است اطلاعی ندارد.

لیست وضعیت ابطال گواهی

کلیدهای تصدیق را می توان به دلایلی باطل کرد، از جمله سوء استفاده یا استخراج مشکوک توسط مهاجم. بنابراین، بسیار مهم است که وضعیت هر گواهی در یک زنجیره گواهی با فهرست وضعیت ابطال گواهی رسمی (CRL) بررسی شود. این فهرست توسط گوگل نگهداری می شود و در آدرس زیر منتشر شده است: https://android.googleapis.com/attestation/status . سرآیند Cache-Control در پاسخ HTTP تعیین می‌کند که هر چند وقت یک‌بار برای به‌روزرسانی‌ها بررسی شود، بنابراین برای هر گواهی تأیید شده نیازی به درخواست شبکه نیست. این نشانی وب یک فایل JSON حاوی وضعیت ابطال گواهی‌هایی که وضعیت معتبر عادی ندارند را برمی‌گرداند. فرمت فایل JSON مطابق با تعریف طرحواره JSON ( پیش‌نویس 07 ) زیر است:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "entries": {
      "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
      "type": "object",
      "propertyNames": {
        "pattern": "^[a-f1-9][a-f0-9]*$"
      },
      "additionalProperties": {
        "type": "object",
        "properties": {
          "status": {
            "description": "[REQUIRED] Current status of the key.",
            "type": "string",
            "enum": ["REVOKED", "SUSPENDED"]
          },
          "expires": {
            "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
            "type": "string",
            "format": "date"
          },
          "reason": {
            "description": "[OPTIONAL] Reason for the current status.",
            "type": "string",
            "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
          },
          "comment": {
            "description": "[OPTIONAL] Free form comment about the key status.",
            "type": "string",
            "maxLength": 140
          }
        },
        "required": ["status"],
        "additionalProperties": false
      }
    }
  },
  "required": ["entries"],
  "additionalProperties": false
}

مثال CRL:

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

سیاست ابطال گواهی

گواهی ستون فقرات سوء استفاده و اعتماد در اکوسیستم اندروید را تشکیل می دهد. این یک بیانیه رمزنگاری قابل تأیید برای طرف های خارج از دستگاه در مورد وضعیت بوت شدن دستگاه ارائه می دهد.

به دلیل ماهیت حیاتی اعتبار گواهی، زمانی که کلیدها در معرض خطر قرار گیرند، گواهی‌های مربوط به کلیدهای تأیید گواهی باطل می‌شوند. این بخش خط مشی ای را برای زمان باطل شدن گواهینامه ها بیان می کند. این سیاست احتمالاً در طول زمان تکامل یافته و موارد بیشتری را برمی‌شمارد.

چه چیزی واجد شرایط ابطال است؟

نشت کلید تأیید فقط بر مکانیسم تأمین قدیمی‌تر پشتیبانی شده در Android تأثیر می‌گذارد و برای کلیدهای تأیید تأیید شده توسط مکانیسم تأمین کلید از راه دور جدیدتر اعمال نمی‌شود.

کلیدهای تصدیق که فاش شده اند همیشه واجد شرایط ابطال گواهی هستند. نشت ها به روش های مختلفی قابل کشف هستند، از جمله:

تجزیه و تحلیل داده های گواهی در طبیعت.
کشف کلیدهای گواهی در رسانه های اجتماعی یا سایر سایت های عمومی.
گزارش مستقیم از محققان امنیتی.

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