حافظهٔ ابری Google کلید را به دستگاه می‌سپارد؛ ادعای حریم خصوصی زیر ذره‌بین

تیم Private AI Compute در یادداشت Google DeepMind در ۲۳ سپتامبر ۲۰۲۶ معماری حافظهٔ پایدار و بین‌دستگاهی این سامانه را شرح داد. طبق این طرح، اطلاعاتی که دستیار برای ادامهٔ کار لازم دارد در پایگاه دادهٔ جداگانهٔ هر کاربر در ابر رمزگذاری می‌ماند و کلیدهای لازم برای گشودن آن به دستگاه‌های شخصی او وابسته است. وعدهٔ این طراحی آن است که محتوای ذخیره‌شده حتی برای خود Google هم خواندنی نباشد؛ متن خوانا فقط هنگام رسیدگی به درخواست مجاز، در محیط پردازش ایزوله پدیدار می‌شود.

این خبر دربارهٔ طراحی یک لایهٔ حافظه برای Private AI Compute است و هنوز نام محصولی که آن را در اختیار عموم بگذارد یا تاریخ عرضهٔ عمومی مشخص نشده است. تحلیل Model Current نیز دامنهٔ ادعای حریم خصوصی را به کارکرد کلیدهای دستگاه، جداسازی سخت‌افزاری و کنترل نسخهٔ نرم‌افزار گره می‌زند. ممیزی مستقلِ سفارش‌داده‌شده از سوی Google شواهدی دربارهٔ بخش‌های بررسی‌شده فراهم کرده، اما وضعیت حذف حافظه و محدودهٔ کد و زیرساخت ارزیابی‌شده همچنان برای سنجش این وعده اهمیت دارند.

حافظهٔ پایدار چه چیزی را در Private AI Compute عوض می‌کند؟

نسخهٔ پیشین Private AI Compute درخواست را در محیط ابری ایزوله پردازش می‌کرد و پس از پایان کار، زمینهٔ موقت آن را کنار می‌گذاشت. چنین پردازشی برای پاسخ به همان درخواست کافی است، اما دستیار در نشست بعدی حافظه‌ای از آن مسیر ندارد. لایهٔ تازه قرار است زمینهٔ لازم را میان نشست‌ها نگه دارد تا کاربر بتواند گفت‌وگو را از تلفن همراه در وب ادامه دهد، یا اطلاعاتی را که از دستگاه دیگری دیده است دوباره به کار بگیرد. این استمرار از راه ذخیرهٔ رکورد رمزگذاری‌شده در سرور به دست می‌آید، بدون آنکه نسخهٔ خوانای حافظه روی همهٔ دستگاه‌ها کپی شود.

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

دستگاه، محیط ایزوله و پایگاه داده چگونه به هم می‌رسند؟

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

هنگام نیاز به زمینهٔ قبلی، دستگاه از کانالی رمزگذاری‌شده و احراز هویت‌شده به محیط پردازش محافظت‌شده وصل می‌شود. درون این محیط ایزوله، داده برای مدت لازم باز می‌شود تا درخواست پردازش و حافظه در صورت نیاز به‌روزرسانی شود؛ محتوای تازه پیش از بازگشت به ذخیره‌سازی پایدار دوباره رمزگذاری می‌شود. بنابراین «کلید روی دستگاه» به این معنا نیست که محاسبه به‌طور کامل روی تلفن یا رایانه انجام می‌شود. توان پردازشی همچنان در ابر است و مرز مهم، جایی است که متن خوانا موقتاً در حافظهٔ ایزوله حضور دارد.

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

وعدهٔ «حتی Google نمی‌تواند بخواند» تا کجا می‌رود؟

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

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

ممیزی مستقل چه شواهدی و چه پرسش‌هایی بر جای گذاشت؟

در گزارش ممیزی Trail of Bits، ۱۰ مسئله در بررسی سفارش‌داده‌شده از سوی Google ثبت شد؛ ۸ مورد تا گزارش نهایی رفع شده بود و ۲ مورد باز مانده بود. در بخش ارزیابی‌شدهٔ کد، سازوکاری یافت نشد که یک کارمند Google به‌تنهایی از آن برای خواندن دادهٔ کاربر استفاده کند. این نتیجه به همان نسخه و بخش‌های ارزیابی‌شده تعلق دارد؛ بخش‌هایی از کد بسته بودند و بعضی اجزای زیرساخت در دامنهٔ کار قرار نداشتند.

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

در مرحلهٔ عرضه، معنای عملی وعدهٔ حریم خصوصی به پاسخ چند پرسش وابسته خواهد بود: حافظه و نسخه‌های پشتیبان پس از فرمان حذف چه سرنوشتی دارند، دستگاه تازه چگونه حق دسترسی می‌گیرد، و اگر همهٔ دستگاه‌های دارای راز دسترسی از دست بروند بازیابی حساب چگونه انجام می‌شود؟ همچنین باید روشن شود نسخه‌ای که واقعاً در محصول اجرا می‌شود در چه دامنه‌ای ممیزی شده و دستگاه چگونه همان نسخه را تشخیص می‌دهد. انتشار قواعد حذف و بازیابی برای یک محصول مشخص، همراه با روش جلوگیری از بازگرداندن رکورد قدیمی، آزمون عملی بعدی این وعده خواهد بود.