لماذا لا يمكن لتشفير النماذج على الجهاز أن يحل محل تفويض واجهة برمجة التطبيقات (API)

تفكيك تطبيقات الذكاء الاصطناعي المحمولة إلى سبع فئات من الأصول

غالبًا ما يتم تبسيط أمان الذكاء الاصطناعي المحمول ليقتصر على ما إذا كان النموذج مشفرًا أم لا. في الواقع، يشمل سطح الهجوم على الأقل ملفات النماذج، وأوقات تشغيل الاستدلال، والمعالجة المسبقة للمدخلات، والمعالجة اللاحقة للمخرجات، والمطالبات أو قواعد الأعمال، واعتماديات واجهة برمجة التطبيقات عن بُعد، وبيانات المستخدم، والسجلات. تحمل كل فئة من فئات الأصول عواقب مختلفة عند التسرب، وآليات تحديث مميزة، ومسؤوليات ملكية منفصلة.

قد يؤدي نسخ أوزان النموذج إلى سرقة الملكية الفكرية وفقدان القدرة التجارية؛ بينما يمكن لتعديل قوالب المطالبات أو منطق المعالجة اللاحقة تغيير سلوك الأعمال؛ وقد يؤدي تسريب مفاتيح واجهة برمجة التطبيقات (API) طويلة الأمد مباشرة إلى خسائر مالية، أو وصول غير مصرح به للبيانات، أو إساءة استخدام الموارد؛ وقد تحتوي سجلات المدخلات/المخرجات على بيانات خصوصية للمستخدم. إن حماية ملف النموذج فقط تفشل في تغطية هذه المخاطر المتبقية.

يجب أن يوثق سجل الأصول موقع التخزين، ومصدر الإنشاء، ومسار النقل، وأنماط الاستخدام أثناء وقت التشغيل، وآليات التحديث والاسترجاع، ومبادئ أقل امتياز، ونطاق السجل، وفترات الاحتفاظ. لا ينبغي اعتبار الأصول التي لا يوجد لها دورة حياة محددة محمية بمجرد تفعيل مفتاح التشفير.

يجب أن تصبح ملفات النماذج مواد قابلة للاستخدام أثناء وقت التشغيل

سواء أكان الاستخدام عبر Core ML أو LiteRT أو بيئات تشغيل أخرى على الجهاز، يجب تحميل النماذج وتحليلها وإشراكها في العمليات الحسابية. يقلل التشفير على مستوى الملفات من سهولة النسخ المباشر من حزم التثبيت أو مجلدات التطبيق، لكنه لا يمنع التطبيق قيد التشغيل من الوصول إلى مواد النموذج. إذا سيطر مهاجم على العملية أو راقب بيئة التشغيل، يتحول نموذج الخطر من الملفات الثابتة إلى مراحل التحميل والذاكرة واستدعاءات الدوال والمخرجات.

لا يعني هذا أن تشفير النماذج عديم الفائدة؛ بل يرفع تكلفة عمليات النسخ منخفضة الجهد، ويمنع الاستبدال المباشر، ويشكّل جزءاً من استراتيجية الدفاع المتعمق إلى جانب حماية الحزمة وفحوصات السلامة واكتشاف بيئة التشغيل ومزاوجة الإصدارات. المفتاح هو صياغة الفائدة بوصفها زيادة في تكلفة الهجوم وتقليصاً لسطح التعرض، بدلاً من الادعاء باستحالة الاستخراج.

تطرح تحديثات النماذج أيضاً تحديات في التوافق. يجب مزاوجة إصدارات النماذج مع منطق المعالجة المسبقة وأشكال الميزات وإصدارات بيئة التشغيل وقدرات العتاد وقواعد المعالجة اللاحقة. تتطلب حالات فشل التحديث عمليات تراجع آمنة لمنع توليفات عشوائية بين نماذج قديمة ومنطق جديد.

مفاتيح واجهة برمجة التطبيقات طويلة الأمد عالية الامتياز لا ينبغي أن تكون أسراراً على العميل

تنص وثائق أمان أندرويد صراحةً على أن مفاتيح واجهة برمجة التطبيقات المضمّنة في الكود المصدري قد تُكتشف عبر إزالة التجميع بعد بناء التطبيق. يمكن لإخفاء الهوية وتقوية التطبيق رفع تكلفة العثور عليها، لكنهما لا يغيّران حقيقة أن العميل يجب أن يحتفظ بهذه الاعتمادات ويستخدمها. طالما بقي المفتاح طويل الأمد وعالي الامتياز ضمن عميل عام، يصعب احتواء أثر تسربه.

يمكن لمخزن مفاتيح أندرويد إبقاء بعض مواد المفاتيح غير قابلة للتصدير، لكن الوثائق الرسمية توضح أنه إذا اختُرقت عملية التطبيق، فقد يتمكن المهاجمون من استخدام مفاتيح التطبيق لتنفيذ عمليات. إنه مناسب لحماية المفاتيح الخاصة المقيدة بالجهاز والتشفير المحلي، لكن لا ينبغي تفسيره خطأً بوصفه خزناً آمناً لأسرار مشتركة طويلة الأمد اعتباطية للخدمات البعيدة.

يتطلب تصميم أكثر متانة أن يطلب العميل رموزاً قصيرة العمر مقيدة وقابلة للإلغاء من خدمته الخاصة استناداً إلى هوية المستخدم وسياق الجهاز، أو أن يتولى وكيل من جانب الخادم معالجة استدعاءات النماذج عالية المخاطر. يجب على الخادم فرض تفويض الحساب والحصص وحدود المعدل ونطاق النموذج ونطاق البيانات ومراقبة السلوك الشاذ.

• عزل الاعتمادات حسب بيئات التطوير والاختبار والإنتاج
• ضمان امتلاك الرموز لأدنى صلاحيات للنموذج والبيانات
• تمكين الإلغاء من جانب الخادم وفرض الحصص وحدود المعدل
• منع العملاء من تخزين مفاتيح مشتركة طويلة الأمد عالية الامتياز

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

إشارات السلامة يجب أن تُغذي قرارات جانب الخادم فقط

توفر Play Integrity للخلفيات الخادمة في أندرويد إشارات تتعلق بهوية التطبيق، وسلامة الجهاز، وترخيص الحساب، والمخاطر البيئية الجزئية. تساعد Apple App Attest الخادم على تحديد ما إذا كان الطلب صادرًا عن نسخة تطبيق صالحة من خلال توليد مفاتيح خاصة بالجهاز، وإصدار تحديات لمرة واحدة، والتحقق من التوثيق على الخادم، ومعالجة التأكيدات اللاحقة. القاسم المشترك هو أن الأدلة يتم التحقق منها نهائيًا بواسطة الخادم.

تمتلك هذه الآليات حدودًا واضحة. تتأثر الإشارات المتعلقة بـ Play بمصادر التوزيع، وحالة الجهاز، وظروف الخدمة؛ وتشير وثائق آبل إلى أن App Attest غير مدعومة على جميع أنواع الأجهزة، وأنه لا توجد سياسة واحدة تقضي على الاحتيال بالكامل. يجب على الخادم التمييز بين حالات النجاح، والفشل، وعدم التوفر، والأخطاء العابرة، والحالات غير المُهيأة. ولا ينبغي مساواة حالة "غير متوفر" مباشرةً بهجوم، كما لا يجب إجراء الأحكام النهائية محليًا على جانب العميل.

تعالج إشارات السلامة وتشفير النماذج مشكلتين مختلفتين. يساعد الأول في التحقق من نسخ التطبيق وبيئات وقت التشغيل، بينما يقلل الثاني من تعرض النموذج الثابت. لا يزال التفويض الحقيقي يتطلب سياق الحساب، وفحص موارد الأعمال، والتحقق من الإصدار، وتحليل محتوى الطلب، وإنفاذ الحصص، والسياق السلوكي.

يتطلب التحقق من أمان تطبيقات الذكاء الاصطناعي المحمولة وجهات نظر ثابتة، ووقت تشغيل، وجانب خادم

تجيب الفحوصات الثابتة عن النماذج، والإعدادات، والسلاسل النصية، وبيانات الاعتماد، وموارد التصحيح الموجودة في حزمة التثبيت؛ وتجيب فحوصات وقت التشغيل عن كيفية تحميل النماذج، وكيفية معالجة الأعطال، وما إذا كانت السجلات تسرب البيانات، وإذا كان يمكن للتحديثات التراجع؛ وتجيب فحوصات جانب الخادم عن مدى إنفاذ الحساب، والإصدار، والسلامة، والحصص، وأذونات البيانات فعليًا. يؤدي غياب أي من هذه الأنواع الثلاثة من الأدلة إلى تحيز الاستنتاجات نحو وجهات نظر جزئية.

يجب أن يستخدم الاختبار مرشحات إصدار فريدة وإصدارات نموذج صريحة، مع توثيق الأنظمة المستهدفة، وقدرات الجهاز، وخلفيات وقت التشغيل، ومصادر النموذج، وحالات التحديث. يعتمد أداء الاستدلال على الجهاز، واستخدام الذاكرة، والتوافق على بنية النموذج، والكمّنة، والأجهزة، ووقت التشغيل؛ ولا يمكن الاستشهاد بأرقام مستمدة من نماذج أو أجهزة أخرى.

مسارات الاستثناء حاسمة: ملفات النموذج المفقودة أو التالفة، والتحديثات المقطوعة، وأوقات التشغيل غير المدعومة، ورموز الخادم منتهية الصلاحية، وإشارات السلامة غير المتاحة، وفشل رفع السجلات، وأذونات المستخدم الملغاة. يجب أن يتدهور النظام بشكل آمن، مما يوفر حالات قابلة للاسترداد لكل من المستخدمين وفرق العمليات.

استنتاجات التصميم وحدود النطاق

يُعد تشفير النموذج أمرًا مجديًا، لكنه يمثل نقطة تحكم واحدة فقط ضمن دورة حياة النموذج. تحتاج تطبيقات الذكاء الاصطناعي التجارية أيضًا إلى حماية منطق المعالجة المسبقة واللاحقة، ومنع دخول مفاتيح الامتيازات العالية طويلة الأمد إلى العميل، وضمان قيام الخادم بالمصادقة النهائية، وتنفيذ تحمل الأعطال لإشارات نزاهة المنصة، وحوكمة بيانات المستخدم والسجلات.

بدون مرشحات الإصدار الفعلية وإصدارات النماذج والأجهزة المستهدفة وواجهات جانب الخادم، لا يمكننا سوى مراجعة البنية المعمارية وعناصر التحقق المعلقة. لا يمكننا الادعاء بأن النماذج محصنة ضد الاستخراج، أو أن الواجهات محصنة ضد إساءة الاستخدام، أو أن حقن وقت التشغيل مُمنوع، أو أن أهداف الأداء قد تحققت. تتطلب أي استنتاجات من هذا القبيل حزم أدلة حالية.

نقطة الدخول للإجراء الخاصة بـ Yudun في هذه الصفحة مخصصة لطلب تقوية التطبيق وتقييم التوافق؛ ولا تمثل تحققًا من أي إطار عمل نموذج محدد أو قدرة حصرية للذكاء الاصطناعي. يجب تأكيد نطاق المشروع بشكل منفصل بعد تقديم مجموعة التقنيات وطريقة تسليم النموذج ومسارات الأعمال الحرجة.

• الحفاظ على سجلات منفصلة للنماذج وبيئات التشغيل وأوراق الاعتماد والبيانات
• ضمان المصادقة النهائية للاستدعاءات عالية الخطورة بواسطة الخادم
• توفير مسارات عدم التوفر والتدهور لإشارات المنصة
• تمكين تحديثات النماذج لدعم التحقق والتبديل الذري والاسترجاع
• ربط جميع الاستنتاجات بمرشحات الإصدار وإصدارات النماذج المحددة