Keystore: ما هو، وما هي التنسيقات الموجودة وكيف يعمل

ما هو Keystore

Keystore (KeyStore) هو آلية قياسية في Java Cryptography Architecture (JCA) لتخزين المفاتيح التشفيرية والشهادات والإدخالات الموثوقة. في تطوير Android، يُستخدم Keystore لتخزين المفتاح الخاص الذي يُوقع به التطبيق قبل النشر. يضمن التوقيع أن التطبيق قد نُشر بالفعل بواسطة المطور المحدد وأن كوده لم يتم تغييره بعد النشر. يجب توقيع كل تحديث للتطبيق بنفس المفتاح، وإلا سيرفض Google Play ملف APK أو App Bundle.

يمكن أن يحتوي Keystore على عدة إدخالات (aliases)، كل منها يمثل زوج مفاتيح (خاص وعام) مع شهادة. Alias هو اسم إدخال فريد يصل به التطبيق إلى المفتاح أثناء التوقيع. في مشروع Android النموذجي، يحتوي Keystore على إدخال واحد لتوقيع إصدار الإصدار وقد يحتوي على إدخالات إضافية لتوقيع بنيات التصحيح. تعرض Google Play Console بصمات SHA-1 و SHA-256 للشهادة لكل تطبيق تم تحميله.

يتضمن Android Studio دعمًا مدمجًا لـ Keystore من خلال قائمة Build → Generate Signed Bundle / APK. معالج التوقيع في Android Studio يسمح بإنشاء Keystore جديد أو اختيار موجود، وتحديد alias، وكلمات مرور Keystore والمفتاح، بالإضافة إلى بيانات الشهادة (اسم المؤسسة، المدينة، الدولة). تُدمج هذه البيانات في الشهادة وتكون مرئية للمستخدمين عند التحقق من توقيع APK. يتطلب Google Play أن تكون صلاحية الشهادة 25 عامًا على الأقل؛ يتحقق Android من تاريخ انتهاء الصلاحية عند تثبيت التطبيق.

لماذا Keystore مهم لـ Android

تحديثات التطبيق في Google Play ممكنة فقط بنفس المفتاح الذي وقع الإصدار الأول. إذا فُقد Keystore، يستحيل نشر تحديث — سيتعين إعادة نشر التطبيق باسم حزمة مختلف. وفقًا لـ Google Play Console Help (2026)، يمكن استرداد مفتاح توقيع التطبيق فقط من خلال Google Play App Signing — وهي خدمة تخزن المفتاح على جانب Google. إذا استخدم المطور هذا الخيار، فإن فقدان Keystore المحلي ليس حرجًا.

كيف يعمل Keystore

تتضمن عملية توقيع تطبيق Android إنشاء ملخص (hash) لمحتويات APK وتشفيره بالمفتاح الخاص من Keystore. Android SDK Build Tools تتضمن أداة apksigner التي تنفذ التوقيع باستخدام APK Signature Scheme v2 (أو v3 لنظام Android 9+). عند تثبيت التطبيق، يتحقق Android من التوقيع: يفك تشفير التوقيع بالمفتاح العام للشهادة، ويقارن hash APK مع الأصلي — إذا لم تتطابق الـ hashes، يُرفض التثبيت.

يدعم Android عدة مخططات توقيع: v1 (JAR signing)، v2 (APK Signature Scheme)، v3 (APK Signature Scheme مع دعم تدوير المفاتيح) و v4 (التثبيتات المتزايدة لنظام Android 11+). يتطلب Google Play v2 أو v3 للتطبيقات الجديدة. يضيف apksigner تلقائيًا جميع المخططات الضرورية أثناء التوقيع إذا كان المفتاح يدعم الخوارزميات المقابلة. Android 11+ يدعم تثبيت ADB بتوقيع v4، مما يسرع التحميل المتزايد لملفات APK الكبيرة على الجهاز.

الخوارزميات: يوصي Android باستخدام RSA-2048 أو ECDSA P-256 لمفتاح التوقيع. يجب أن تكون الشهادة X.509 v3. يتحقق Android من أن الشهادة صالحة في وقت التثبيت — إذا انتهت صلاحيتها، يُحظر التثبيت. لهذا السبب يوصي Google بتعيين فترة صلاحية الشهادة على 25 عامًا على الأقل. Google Play App Signing يستخدم مفتاحين: مفتاح توقيع التطبيق (app signing key) ومفتاح التحميل (upload key) — يُستخدم مفتاح التحميل من قبل المطور لتحميل APK إلى Console، ويوقع Google التطبيق للمستخدمين بالمفتاح الرئيسي.

تنسيقات Keystore: JKS و PKCS12

يدعم Java تنسيقين رئيسيين لـ Keystore: JKS (Java KeyStore) — تنسيق مملوك لشركة Oracle موجود منذ JDK 1.2، و PKCS12 — التنسيق الموحد Public-Key Cryptography Standards #12 من RSA Laboratories. يستخدم JKS تنسيق تخزين بيانات خاص به وهو مدعوم فقط داخل النظام البيئي Java. PKCS12 هو معيار مفتوح مدعوم من Java و .NET و OpenSSL و Python (cryptography) ومعظم مكتبات التشفير الأخرى.

يوصي Google Play باستخدام PKCS12 كتنسيق مفضل لـ Keystores الجديدة التي تم إنشاؤها بعد عام 2021. JDK 9 والإصدارات الأحدث تنشئ Keystores بتنسيق PKCS12 افتراضيًا (كان التنسيق الافتراضي سابقًا JKS). الميزة الرئيسية لـ PKCS12 هي التوافق: يمكن فتح ملف .p12 في أي بيئة غير مرتبطة بـ Java. يمكن لـ OpenSSL استخراج الشهادات من PKCS12 وتحويلها إلى تنسيق PEM. تتطلب ملفات JKS أدوات JDK للقراءة ولا يمكن معالجتها بواسطة OpenSSL.

يتم التحويل بين التنسيقات باستخدام أداة keytool من JDK. عند الترحيل من JKS إلى PKCS12، تأكد من نقل جميع الأسماء المستعارة (aliases) وكلمات المرور بشكل صحيح. يسمح أمر keytool -importkeystore باستيراد محتويات Keystore إلى آخر بغض النظر عن التنسيق. بعد التحويل، من الأفضل حذف ملف JKS القديم لتجنب الارتباك مع إصدارات المفتاح. Android Studio يدعم كلا التنسيقين عند إنشاء بناء موقع.

إنشاء Keystore باستخدام keytool

أداة keytool هي جزء من JDK (Java Development Kit) وتوفر مجموعة كاملة من الأوامر لإنشاء وعرض وإدارة Keystores. لإنشاء Keystore جديد بزوج مفاتيح واحد، يُستخدم الأمر keytool -genkeypair مع تحديد تنسيق PKCS12، وخوارزمية RSA، وحجم المفتاح وفترة صلاحية الشهادة. يتطلب Google Play صلاحية شهادة لا تقل عن 25 عامًا (9125 يومًا) — يوصى بتحديد هذه القيمة في المعامل -validity.

إنشاء Keystore جديد

مثال على إنشاء Keystore بتنسيق PKCS12 لمشروع Android. يحتوي المعامل -dname على الاسم المميز X.500 للشهادة. يتضمن المعامل -ext Subject Alternative Name إذا لزم الأمر — بالنسبة لـ Android، Basic Constraints كافية:

# إنشاء Keystore PKCS12 لنظام Android
keytool -genkeypair -alias "upload_key" \
  -keyalg RSA -keysize 2048 -validity 9125 \
  -keystore "release-keystore.p12" \
  -storetype PKCS12 \
  -dname "CN=Developer,O=Company,C=RU"

Keytool سيطلب كلمة مرور Keystore وكلمة مرور المفتاح (يمكن أن تتطابق). المعامل -storetype PKCS12 ينشئ ملفًا بالتنسيق الحديث. -keysize 2048 يتوافق مع متطلبات Google للحد الأدنى لحجم مفتاح RSA. -validity 9125 (25 عامًا) يضمن التوافق طوال دورة الحياة المتوقعة للتطبيق. بعد إنشاء Keystore، يوصى بالتحقق من محتوياته بالأمر keytool -list -v -keystore release-keystore.p12.

عرض محتويات Keystore

للتحقق من إدخالات Keystore، يُستخدم الأمر مع العلم -list. يتضمن الإخراج الاسم المستعار وتواريخ الإنشاء والانتهاء ونوع الإدخال وبصمات SHA-256. Android Studio يعرض نفس المعلومات في مربع حوار Generate Signed Bundle / APK عند اختيار Keystore موجود:

# عرض إدخالات Keystore
keytool -list -v -keystore "release-keystore.p12" \
  -storetype PKCS12

استخدام Keystore في CI/CD

في خط أنابيب CI/CD، يجب تخزين Keystore بشكل آمن ونقله إلى وكيل البناء دون خطر الاختراق. GitHub Actions يوفر Secrets لتخزين الملفات الثنائية بتنسيق base64. يتم ترميز Keystore باستخدام أمر base64، ويتم حفظ السلسلة الناتجة في أسرار المستودع، وفي مرحلة البناء يتم فك تشفيرها مرة أخرى إلى ملف. GitLab CI يستخدم آلية مماثلة من خلال Variables من نوع File.

مثال على إعداد بناء CI مع Keystore في GitHub Actions يتضمن فك تشفير Keystore من سر، وتكوين خصائص Gradle، وتنفيذ بناء موقع. Gradle، إضافة Android، يقرأ مسار Keystore وكلمات المرور من ملف keystore.properties (مستبعد من .gitignore للتطوير المحلي) أو من متغيرات بيئة نظام CI:

// build.gradle (app) — تكوين التوقيع
@Override
android {
    signingConfigs {
        release {
            storeFile file("release-keystore.p12")
            storePassword System.getenv("STORE_PASSWORD")
            keyAlias System.getenv("KEY_ALIAS")
            keyPassword System.getenv("KEY_PASSWORD")
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Gradle يقرأ متغيرات البيئة التي يحددها نظام CI. يجب أن يكون ملف Keystore موجودًا في جذر وحدة التطبيق، كما هو محدد في storeFile. للأمان، لا تخزن كلمات المرور أبدًا في المستودع — استخدم Secrets نظام CI. Fastlane لنظام Android يوفر إضافة supply، التي تعمل مع Google Play Console، لكن توقيع APK لا يزال يتطلب Keystore محليًا على الوكيل.

بديل هو Google Play App Signing. عند استخدام هذا الخيار، يقوم المطور بتحميل مفتاح التحميل (upload key) فقط إلى Google Play، ويوقع Google ملف APK النهائي بمفتاحه الخاص. في هذه الحالة، يُستخدم Keystore فقط لإنشاء مفتاح التحميل، وفقدانه لا يمنع التحديثات — يمكن إنشاء مفتاح تحميل جديد وتسجيله في Console. Google Play App Signing إلزامي للتطبيقات الجديدة منذ أغسطس 2021.

أمان Keystore والنسخ الاحتياطي

فقدان Keystore هو أحد أكثر المشكلات حرجًا في تطوير Android. بدون نسخة احتياطية، يستحيل إصدار تحديث لتطبيق موجود — يرفض Google Play ملفات APK الموقعة بمفتاح مختلف. يُوصى بالاحتفاظ بنسختين احتياطيتين على الأقل من Keystore في مخازن فعلية أو سحابية مختلفة: على سبيل المثال، ملف مشفر في التخزين السحابي للفريق ووسيط مادي في خزنة المؤسسة. يتم تخزين كلمات مرور Keystore والمفتاح بشكل منفصل عن الملف، على سبيل المثال، في مدير كلمات مرور مع التحكم في الوصول.

Android Studio، عند إنشاء Keystore جديد في مربع حوار Generate Signed Bundle / APK، يعرض تذكر المسارات للبنيات المستقبلية. ومع ذلك، فإن بيئة التطوير نفسها لا تنشئ نسخة احتياطية — هذه مسؤولية المطور. للتطوير الجماعي، يُوصى باستخدام Google Play App Signing مع نقل مفتاح التحميل عبر قناة آمنة لجميع أعضاء الفريق. Gradle يمكنه توقيع بنيات التصحيح تلقائيًا باستخدام debug.keystore المُنشأ، والذي لا يتطلب نسخًا احتياطيًا — وهو نفسه لجميع تثبيتات Android Studio.

أمان Keystore أثناء النقل: يجب نقل ملفات .p12 أو .jks فقط عبر قنوات مشفرة (SFTP، HTTPS، مرفقات بريد إلكتروني مشفرة). لا تقم أبدًا بتضمين Keystore في مستودع الكود المصدري — حتى لو كان خاصًا. GitGuardian أو فحص أسرار GitHub يكتشفان تلقائيًا نشر بيانات الاعتماد، لكن تخزين Keystore في مستودع لا يزال انتهاكًا أمنيًا. بالنسبة لـ CI/CD، استخدم آلية الأسرار الخاصة بالمنصة (GitHub Actions Secrets، GitLab CI Variables، Jenkins Credentials) مع التشفير على مستوى البنية التحتية.