رمزگذاری دیسک روی دستگاهی اجاره‌ای

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

سه حالت، و همانی که هیچ‌کس رمزگذاری نمی‌کند

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

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

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

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

کلید در زمان اجرای دستگاه کجاست

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

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

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

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

مسئلهٔ راه‌اندازی مجدد، و میان‌بری که آن را بی‌اثر می‌کند

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

چهار روش برای باز کردن قفل یک حجم ریشهٔ رمزگذاری‌شده روی دستگاهی دوردست

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

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

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

رمزگذاری کامل دیسک واقعاً چه چیزی به دست می‌دهد

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

هشت سناریو، و اینکه آیا رمزگذاری کامل دیسک نتیجه را تغییر می‌دهد

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

فراتر از دیسک: چه چیزی در برابر یک میزبان خصمانه دوام می‌آورد

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

رمزگذاری در لایهٔ بالاتر از برنامه، نه زیر آن

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

پشتیبان‌گیری تصمیمی جداگانه است، نه پیامدی خودکار

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

رمزگذاری حافظه، و چرا احتمالاً در اختیار نیست

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

پیکربندی‌ای که دربارهٔ محدودیت‌های خود صادق است

هیچ‌کدام از این‌ها به زحمتش را نکشید ختم نمی‌شود. بلکه به پیکربندی‌ای ختم می‌شود که بتوان محدودیت‌هایش را بی‌تردید بلند گفت.

1. نوشتن همان یک سناریویی که در برابرش دفاع می‌شود (5 دقیقه). دیسکی از رده خارج، دستگاهی که در حال اجرا توقیف شده، میزبانی خصمانه، حکمی قضایی، نشتی که باید افشا شود. هرکدام پاسخ متفاوتی دارند، و پیکربندی‌ای که برای هر پنج مورد طراحی شده، به‌طور قابل‌اطمینان هیچ‌کدام را برآورده نمی‌کند.
2. قرار دادن رمزگذاری در همان‌جایی که کلید هست (تصمیم). اگر کلید در اختیار ارائه‌دهنده باشد، فقط محافظتی در برابر بیرون رفتن دیسک از ساختمان خریداری شده و نه چیزی فراتر از آن. اگر محافظتی بیش از این مدنظر است، حجم باید از درون ماشین مهمان، توسط مالک، و با چیزی که پلتفرم هرگز نمی‌بیند باز شود.
3. رمزگذاری حجم داده به‌جای حجم ریشه (پیکربندی). ریشهٔ رمزگذاری‌شده یعنی هر راه‌اندازی مجدد منتظر یک انسان می‌ماند. یک حجم رمزگذاری‌شدهٔ جداگانه که پوشهٔ پایگاه‌داده، فایل‌های بارگذاری‌شده و اطلاعات محرمانه را در خود دارد، اجازه می‌دهد دستگاه خودش دوباره بالا بیاید، در حالی که بخش حساس بسته می‌ماند تا زمانی که باز شود. این همان مصالحه‌ای است که بیشتر پلتفرم‌های کوچک باید انجام دهند، و تقریباً هیچ‌کس آن را روی کاغذ نمی‌آورد.
4. هرگز فایل کلید روی پارتیشن بوتِ رمزگذاری‌نشده باقی نماند (قاعده). اگر دستگاه بدون دخالت انسان، بدون سرور کلید و بدون کنسول راه‌اندازی شود، کلید روی همان دیسک است؛ امکان سومی وجود ندارد. این بده‌بستان خوبی است وقتی دیسک دزدیده‌شده واقعاً کل مدل تهدید است، و در هر حالت دیگری، خودفریبی است.
5. رمزگذاری پشتیبان‌ها در همان لحظهٔ نوشتن، با کلیدی نگه‌داری‌شده جای دیگر (پیکربندی). سپس بازیابی یکی از آن‌ها روی دستگاهی دیگر، در روزی که هیچ‌چیز در حال آتش گرفتن نیست.
6. گفتن اینکه چه چیزی پوشش داده شده، در یک جمله (5 دقیقه). چیزی نزدیک به این: مهاجمی که این دیسک را از قفسه بیرون می‌کشد هیچ چیز به دست نمی‌آورد، و هرکسی که روی دستگاه در حال اجرا یا روی میزبان آن دسترسی روت داشته باشد همه‌چیز به دست می‌آورد. اگر نوشتن این جمله ناراحت‌کننده است، دلیلش این است که درست است.

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

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

نوشته‌شده توسط مهندسانی که این پلتفرم را اداره می‌کنند، و بازبینی‌شده در امروز. اگر چیزی اینجا اشتباه یا قدیمی است، آن را از پنل مشتری بگویید — نیمی از این موارد از همان‌جا آمده‌اند.