هیچ رازی پیش از اثبات: محاسبات محرمانه برای هوش مصنوعی

ت

تیم ژرف ای‌آی

۲۸ مرداد ۱۴۰۵۱۴ دقیقه مطالعه
هیچ رازی پیش از اثبات: محاسبات محرمانه برای هوش مصنوعی

شرکتی سابقه‌های مشتری را در ذخیره و انتقال رمز می‌کند، سپس به سرور هوش مصنوعی می‌فرستد؛ جایی که میزبان، هایپروایزر، میان‌افزار، زمان‌اجرا و برنامه بخشی از اعتمادند. وقتی مدل داده را به کار می‌گیرد، چه کسی آن را می‌بیند یا تغییر می‌دهد؟

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

این راهنما سازوکار، خطر باقی‌مانده و معماری قابل‌آزمون آزادسازی راز پس از گواهی را شرح می‌دهد.

از مهاجم شروع کنید، نه از مدل سخت‌افزار

پیش از مقایسه محصول، دارایی حفاظت‌شده، طرفی که نباید به آن دسترسی داشته باشد، لحظه افشا و شکست قابل‌پذیرش را نام ببرید:

سندهای مشتری و وزن‌های اختصاصی مدل فقط در انتشار R-27 رمزگشایی شوند؛ مدیر ابر، هسته میزبان آلوده، هایپروایزر یا مشتری همسایه نتواند آن‌ها را بخواند یا تغییر دهد. قطع خدمت پذیرفتنی است؛ اجرای بی‌صدا در زمان‌اجرای تأییدنشده نیست.

این عبارت لایه نامطمئن و سازگاری رد امن با خدمت را روشن می‌کند.

NIST IR 8320 که در مه ۲۰۲۲ نهایی شد، امنیت سخت‌افزارمحور را پایه امنیت لایه‌ای سکو می‌داند. تحلیل ژرف: محاسبات محرمانه وقتی مفید است که ریشه سخت‌افزاری رابطه اعتماد نام‌داری را تغییر دهد؛ نه برای داده عمومی، میزبان پذیرفته‌شده یا خطر درون برنامه.

مهاجم را صریح دسته‌بندی کنید:

  • بهره‌بردار زیرساخت: فرد ممتاز یا صفحه کنترل آلوده بیرون مهمان؛
  • نرم‌افزار میزبان: هایپروایزر، هسته، راه‌انداز یا عامل مدیریتی مخرب؛
  • مشتری همسایه: بار کاری دیگری که می‌کوشد به حافظه یا دستگاه برسد؛
  • عامل فیزیکی یا زنجیره تأمین: مهاجمی قوی‌تر که شاید بیرون مدل تهدید TEE باشد؛
  • مهاجم داخل مهمان: کد مخرب، خدمت استنتاج آسیب‌پذیر، وابستگی آلوده، تزریق دستور یا سوءاستفاده کاربر در محیط محافظت‌شده.

رده آخر تعیین‌کننده است. TEE مهمان را از بخش‌هایی از میزبان جدا می‌کند؛ کد ناامن داخل مهمان را امن نمی‌سازد.

دقیق بدانید TEE چه چیزی را تغییر می‌دهد

محیط اجرای قابل‌اعتماد معمولاً سه ویژگی جدا می‌آورد:

  1. جداسازی: حافظه و وضعیت اجرای انتخاب‌شده از اجزای مشخص بیرونی محافظت می‌شود؛
  2. اندازه‌گیری: سخت‌افزار یا میان‌افزار محافظت‌شده، ادعاهایی درباره سکو، زنجیره راه‌اندازی، مهمان یا دستگاه ثبت می‌کند؛
  3. گواهی: شاهد امضاشده به راستی‌آزمای بیرونی اجازه می‌دهد پیش از اعتماد، این ادعاها را ارزیابی کند.

این سه هم‌معنا نیستند. رمز حافظه شاید تمامیت ندهد؛ جداسازی بدون گواهی، استقرار را به ادعا تبدیل می‌کند؛ گواهی بدون تصمیم منبع بی‌اثر است.

مقاله فنی AMD درباره SEV-SNP مرز مشخصی دارد: حافظه خصوصی مهمان از هایپروایزر نامطمئن محافظت و با بازپخش، خراب‌سازی و نگاشت دوباره مقابله می‌شود. سند، دسترس‌پذیری مهمان را تضمین نمی‌کند، برای ورودی‌وخروجی مشترک TLS می‌خواهد و همه حمله‌های فیزیکی یا کانال جانبی را حذف نمی‌کند.

این مرز را تعمیم ندهید. نسل پردازنده، میان‌افزار، حالت TEE، سیاست مهمان، مسیر دستگاه، خدمت گواهی و استثناها را ثبت کنید. برچسب محصول، مدل تهدید نیست.

بسنجید آیا پیچیدگی محاسبات محرمانه ارزش دارد

کنترل باید یک شکاف واقعی را ببندد:

وضعیت بار کاریارزش TEEپیام تصمیم
ورودی یا وزن حساس باید از بهره‌بردار زیرساخت پنهان بماندبالقوه زیادمدل تهدید ارائه‌دهنده و دستگاه باید صریحاً دسترسی آن بهره‌بردار به متن آشکار را رد کند
چند طرف داده می‌آورند اما ورودی خام را به یکدیگر نمی‌دهندبالقوه زیادمشخص کنید چه کسی زمان‌اجرا را راستی‌آزمایی و چه کسی هر کلید را کنترل می‌کند
میزبان در مرز اعتماد پذیرفته شده و داده کم‌حساسیت استاغلب کمجداسازی، کنترل دسترسی و رمزنگاری عادی ساده‌تر است
تهدید اصلی تزریق دستور، ابزار ناامن، خطای مدل یا کاربر سوءاستفاده‌گر استکمکنترل برنامه را اصلاح کنید؛ کار زیان‌بار ممکن است به‌درستی داخل TEE اجرا شود
خدمت تحمل رد امن کلید یا قطع راستی‌آزما را ندارددوگانهحالت تنزل امن بسازید یا این معماری را رد کنید

رایانش سخت‌سازی‌شده، ماشین محرمانه و enclave کوچک را مقایسه کنید. مهمان بزرگ ساده‌تر اما TCB بزرگ‌تر است؛ enclave کد مورد اعتماد را کم می‌کند اما تغییر برنامه می‌خواهد. GPU و اتصال دستگاه گزینه‌ها را محدودتر می‌کند.

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

مسیر متن آشکار و پایه محاسبات مورد اعتماد را رسم کنید

هر متن آشکار را دنبال کنید: مشتری، درگاه، صف، حافظه CPU و GPU، بافر مشترک، کش، ذخیره موقت، خروجی، لاگ، dump، ردگیری و ابزار. هسته محافظت‌شده سودی ندارد اگر درگاه prompt را لاگ کند.

برای هر مرحله ثبت کنید:

  • چه کسی متن آشکار را می‌خواند یا تغییر می‌دهد و حافظه خصوصی، مشترک یا قابل‌دید دستگاه است؛
  • هویت و چکیده کد، کلید بازکننده و سامانه مجاز به آزادسازی آن؛
  • مسیر خروج، شاهد فعال‌بودن حفاظت و رفتار حذف، خرابی، retry و بازیابی.

TCB را تعریف کنید: هر سخت‌افزار، میان‌افزار، راستی‌آزما، مهمان، زمان‌اجرا، برنامه و سیاست که خرابی‌اش وعده را می‌شکند. خدمت غیرضروری مهمان نیز عضو آن است.

موجودی را به گذرنامه انتشار هوش مصنوعی وصل کنید. سیاست به هویت تغییرناپذیر مهمان، هسته، راه‌اندازی، برنامه، خدمت مدل، راه‌انداز و سیاست مدل نیاز دارد. latest مرجع نیست.

گواهی را به تصمیم مجوز تبدیل کنید

گواهی از راه دور، جریان شاهد است. RFC 9334، معماری RATS از IETF در ژانویه ۲۰۲۳، سه نقش را جدا می‌کند:

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

امضای معتبر، صادرکننده و تمامیت را ثابت می‌کند؛ نه سازگاری ادعاها با سیاست انتشار.

Google Cloud Attestation نمونه جاری است: تأییدیه می‌گیرد، شاهد را با مرجع و سیاست می‌سنجد و ادعای امضاشده می‌دهد. الگو: گواهی‌دهنده ← راستی‌آزما ← نتیجه ← سیاست طرف اتکاکننده ← تصمیم منبع.

سیاست طرف اتکاکننده را مانند کد نسخه‌بندی کنید:

خانواده ادعاپرسش پیش از آزادسازی
سخت‌افزار و TEEآیا فناوری، نسخه امنیتی، حالت محرمانه و وضعیت debug مجاز است؟
میان‌افزار و راه‌اندازیآیا میان‌افزار، secure boot، هسته، خط فرمان و سیاست مهمان مجاز است؟
بار کاریآیا چکیده تصویر یا برنامه دقیقاً هویت انتشار تأییدشده است؟
دستگاهآیا هر جا راز وارد حافظه GPU می‌شود، ادعای GPU، راه‌انداز، میان‌افزار و اتصال وجود دارد؟
تازگیآیا شاهد به nonce تازه یا سازوکار تازگی پذیرفته‌شده مقید است؟
نشستآیا شاهد کلید عمومی گیرنده راز را در خود مقید کرده است؟
بافتآیا مشتری، محیط، منطقه، هدف و رده خطر با منبع می‌خواند؟
لغوآیا تأییدیه، گواهی، میان‌افزار و مقدار مرجع هنوز پذیرفتنی است؟

غیبت ادعا تأیید نیست؛ شاهد لازم GPU نباید «مورد اعتماد» فرض شود.

بار کاری گواهی‌شده را به کانال راز مقید کنید

گواهی ماشین و ارسال کلید در اتصالی نامرتبط، امکان جایگزینی می‌گذارد. گیرنده راز باید همان بار کاری شاهد باشد.

الگوی مقاوم چنین است:

  1. بار کاری داخل محیط محافظت‌شده یک جفت‌کلید موقت می‌سازد؛
  2. شاهد تازه‌ای می‌گیرد که کلید عمومی، nonce راستی‌آزما و اندازه‌گیری‌های لازم را به هم مقید می‌کند؛
  3. راستی‌آزما شاهد را می‌سنجد و نتیجه کوتاه‌عمر و امضاشده می‌دهد؛
  4. خدمت کلید، صادرکننده، مقصد، تازگی، ادعا، سیاست و بافت درخواست را بررسی می‌کند؛
  5. فقط آنگاه یک کلید باریک داده یا مدل را برای کلید عمومی گواهی‌شده wrap می‌کند؛
  6. بار کاری داخل TEE رمزگشایی می‌کند و پس از کار، کلید نشست را از میان می‌برد.

مایکروسافت این بخش را آزادسازی امن کلید می‌نامد: کلید فقط پس از اثبات TEE آزاد می‌شود. پرسش‌های متداول Azure Attestation مقیدکردن کلید عمومی بار کاری به داده گواهی‌شده را برای ساخت کانال همان محیط مستند می‌کند.

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

کلیدها را بر اساس دارایی و مالک جدا کنید. صاحب مدل و مشتری می‌توانند زمان‌اجرای یکسان اما ادعاهای متفاوت مشتری، جغرافیا، هدف و انقضا بخواهند. همه دارایی‌ها را پشت یک تصمیم attested=true پنهان نکنید.

شتاب‌دهنده هوش مصنوعی را گواهی‌دهنده مرکب بدانید

هوش مصنوعی از مرز CPU و GPU می‌گذرد. حفاظت CPU ثابت نمی‌کند متن آشکار وارد GPU، راه‌انداز، میان‌افزار یا اتصال مجاز شده است. ادعاهای دستگاه باید با هم سنجیده شوند.

معماری مرجع محاسبات محرمانه NVIDIA ماشین محرمانه اندازه‌گیری‌شده، CPU و GPU محرمانه، راستی‌آزما، آزادسازی امن کلید و لاگ حریم‌خصوصی‌محور می‌خواهد؛ همچنین پیش از آزادسازی کلید مدل، شاهد تازه CPU، GPU، مهمان، تنظیم راه‌اندازی و میان‌افزار را لازم می‌داند. مستندات گواهی NVIDIA که ۱ اوت ۲۰۲۶ به‌روز شده، مسیر محلی و راه دور را برای GPUهای پشتیبانی‌شده H100 یا جدیدتر و سوئیچ چند GPU فهرست می‌کند.

این‌ها واقعیت فروشنده‌اند، نه اثبات استقرار. تحلیل ژرف: تصمیم مرکب در غیبت، کهنگی، debug، لغو یا ناسازگاری هر لایه رد امن دهد. نتیجه فروشندگان را یکدست کنید، اما ادعای مؤثر بر مدل تهدید را نه.

سیاست همچنان باید حافظه مشترک، DMA، ورودی‌وخروجی، کش مدل و اتصال چند GPU را پوشش دهد. «GPU گواهی شد» پاسخ جریان داده نیست.

مثال عملی: دو مالک، یک زمان‌اجرای استنتاج

ارائه‌دهنده مالک وزن مدل و مشتری مالک پرونده محرمانه است. هیچ‌کدام به زیرساخت اعتماد ندارد و وزن به تصویر دلخواه داده نمی‌شود. R-27 شامل ماشین اندازه‌گیری‌شده، هسته ثابت، کانتینر کوچک، CPU/GPU مجاز، بازه راه‌انداز و میان‌افزار، debug خاموش و پالایه خروجی است.

ترتیب کار:

  1. زمان‌بند تصویر رمز‌شده را آغاز می‌کند، اما با هویت خدمت عادی به هیچ کلید رمزگشایی نمی‌رسد.
  2. زمان‌اجرا کلید موقت می‌سازد و شاهد تازه CPU، مهمان، GPU، راه‌انداز و میان‌افزار را می‌گیرد که به کلید و چالش راستی‌آزما مقید است.
  3. راستی‌آزما امضا، تأییدیه، نسخه امنیتی، مرجع، تازگی و کامل‌بودن را می‌سنجد و نتیجه کوتاه‌عمر R-27 را برای همان نشست می‌دهد.
  4. خدمت صاحب مدل، انتشار، حالت تولید، هدف، GPU، منطقه و انقضا را می‌سنجد و فقط MK-8 را برای نشست wrap می‌کند.
  5. مشتری جداگانه انتشار، مشتری T-41، هدف، منطقه، نگهداری و اختیار درخواست را می‌سنجد و فقط DK-93 را wrap می‌کند.
  6. زمان‌اجرا در مرز تأییدشده رمزگشایی، استنتاج، اعتبارسنجی و رمزکردن پاسخ را انجام می‌دهد و ماده نشست را پاک می‌کند.
  7. سابقه، چکیده نتیجه، سیاست، انتشار، شناسه کلید، هویت درخواست، تصمیم و رسید را پیوند می‌دهد؛ نه کلید، وزن، prompt، پرونده یا توکن بازاستفاده‌پذیر.

اگر راه‌انداز، شاهد GPU، nonce، تصویر یا سیاست شکست بخورد، کلید همان مالک رد می‌شود. retry فقط روی میزبان تازه و تأییدشده مجاز است؛ نه ماشین عادی یا نتیجه دیروز.

این الگو تماس زیرساخت را کم می‌کند؛ درستی مدل، امنیت کانتینر، مجوز خروجی یا مشروعیت هدف را ثابت نمی‌کند.

شکست، بازیابی و شاهد را پیش از انتشار طراحی کنید

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

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

بازیابی را تمرین کنید. سیاست، مرجع امضا، وضعیت لغو و پیوستگی ممیزی باید حفظ شود؛ منطقه تازه ممکن است مرجع گواهی یا ادعای متفاوت داشته باشد. بازیابی نباید فقط برای رسیدن به RTO مجموعه مورد اعتماد را گسترده کند.

از خود شاهد محافظت کنید. RFC 9334 هشدار می‌دهد که شاهد می‌تواند جزئیات مفید میان‌افزار، نرم‌افزار، دستگاه یا کاربر را فاش کند. آن را کمینه، رمز، محدود و منقضی کنید. معیار راهنمای شواهد ممیزی روشن است: ورودی، سیاست، تصمیم و اثر را برای آزمون کنترل نگه دارید؛ نه تصویر یک نشان سبز.

اطمینان و هزینه عملیاتی را با هم بسنجید

کل مسیر را در برابر رایانش عادی بسنجید، نه فقط یک عدد throughput:

بُعدسنجه مفید
پوششکار حساس با ارزیابی همه ادعاهای لازم CPU، مهمان، GPU و دستگاه
تازگیتوزیع عمر شاهد هنگام آزادسازی؛ شمار رد بازپخش و استفاده دوباره nonce
سیاستآزادسازی و رد به تفکیک نسخه سیاست، ادعا، محیط، مشتری و علت
TCBاجزای اندازه‌گیری‌شده، خدمت ممتاز، تعداد بسته و انحراف چکیده
تماس کلیدآزادسازی بیرون سیاست، عمر راز، یافته dump و استثنای متن آشکار
تغییر امنیتیزمان میان هشدار یا لغو فروشنده تا اصلاح مقدار مرجع و سیاست
قابلیت اتکادسترس‌پذیری راستی‌آزما و کلید، رد امن، عمر صف رمز‌شده و بازیابی
کاراییگواهی، شروع سرد، بار مدل، حافظه، ورودی‌وخروجی، توان عملیاتی، دُم تأخیر و هزینه کار کامل

مدل، بافت، batch، توپولوژی، مسیر داده و سیاست شکست واقعی را معیار بگیرید. سربار آغاز را از هزینه هر درخواست جدا کنید؛ میانگین می‌تواند پرتگاه شروع سرد یا ظرفیت را پنهان کند.

دروازه آزادسازی گواهی‌شده

تا وقتی مالک به این پرسش‌ها پاسخ مثبت نداده، داده یا وزن حساس آزاد نکنید:

  1. آیا دارایی، مهاجم زمان استفاده و مدل تهدید مستند و متناسب TEE روشن است؟
  2. آیا مسیر متن آشکار، از جمله حافظه مشترک و شتاب‌دهنده، لاگ، خروجی و بازیابی رسم شده است؟
  3. آیا TCB عملی کمینه و با مقدار انتشار تغییرناپذیر نام‌گذاری شده است؟
  4. آیا مالک نقش‌های گواهی‌دهنده، راستی‌آزما، مقدار مرجع، سیاست، طرف اتکاکننده و کلید پاسخ‌گو است؟
  5. آیا سیاست برای هر CPU، مهمان، برنامه، GPU، راه‌انداز، میان‌افزار و اتصال مهم شاهد تازه، امضاشده و کامل می‌خواهد؟
  6. آیا کلید نشست گیرنده به‌صورت رمزنگارانه به محیط گواهی‌شده مقید است؟
  7. آیا هر مالک فقط کلیدی باریک برای مشتری، هدف، منطقه، انتشار و انقضای نام‌دار می‌دهد؟
  8. آیا ادعای غایب، کهنه، debug، لغوشده، ناسازگار یا غیرقابل‌راستی‌آزمایی رد امن می‌شود؟
  9. آیا مجوز برنامه، تزریق دستور، اعتبارسنجی خروجی، کیفیت مدل، حریم خصوصی و هدف حقوقی مستقل کنترل می‌شود؟
  10. آیا کارایی، لغو رخداد، قطع تأییدیه، به‌روزرسانی امنیتی، بازیابی منطقه‌ای و نگهداری شاهد تمرین شده است؟

پس از تغییر پردازنده، GPU، میان‌افزار، راه‌انداز، مهمان، راستی‌آزما، قالب، مرجع مقدار، مدیر کلید، زمان‌اجرا، مشتری، منطقه یا توپولوژی تصمیم را بازبینی کنید. افشای کانال جانبی، رد توضیح‌ناپذیر، استثنای اضطراری، نشت متن آشکار یا تمرین بازیابی نیز محرک بازبینی است.

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

یادداشت منابع — بازبینی‌شده در ۱۹ اوت ۲۰۲۶

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

مطالب مرتبط

یک فرایند را برای کشف نیاز مشخص کنید

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