من اخیرا یک نوت بوک جدید با یک درایو SSD خریداری کرده ام. من ویندوز 10 را نصب و پیکربندی کردم (هیچ اطلاعات شخصی تا کنون درگیر نیست)، و سپس VC 1.22 نصب کرده ام و درایو سیستم را رمزگذاری کرده ام (که یک SSD است، همانطور که در بالا گفته شد).
سپس من شروع به فکر کردن درباره آنچه اتفاق افتاده است:
همانطور که همه ما می دانیم، هنگام نوشتن یک فایل به یک هارد دیسک، و سپس تغییر محتویات فایل، لزوما به این معنی نیست که مکان های فیزیکی همان جایی که فایل در اصل در آن قرار داشت، رونویسی می شود. این همیشه در مورد هارد دیسک های معمولی و همچنین SSD ها است، زیرا رفتار معمولی سیستم فایل است.
اکنون چیز جدیدی با SSD ها این است که سخت افزار SSD در هر زمان ممکن است تصمیم بگیرد که مکان فیزیکی را "دوباره" جایی که فایل در ابتدا ساکن بود، در نتیجه جلوگیری از دسترسی O / S به آن منطقه در آینده . این بدان معنی است که اگر شما یک فایل را روی یک SSD بدون رمزگذاری ایجاد کرده و سپس آن فایل یا آن SSD را رمزگذاری کنید، SSD ممکن است نسخه اصلی (بدون رمزنگاری) را در همان حال به یک مکان فیزیکی کپی کند که هرگز به هیچ وجه به آن دسترسی نخواهید یافت حتی این درست پس از درخواست نوشتن O / S اتفاق می افتد.
نکته بد این است که یک دشمن با دانش و ابزار مناسب قادر به خواندن آن فایل ها / زمینه های رمزگذاری نشده است، هر چند که توسط O / S قابل دسترس نیستند.
این دقیقا همان چیزی است که برای من (و احتمالا بسیاری دیگر) اتفاق افتاده است هنگام نصب VC و رمزگذاری درایو. من به VC گفته ام که فایل دیسک نجات را تأیید نکنم، که VC در واقع آن را انجام نداد، اما فایل دیسک نجات را ایجاد کرد و آن را به برخی از دایرکتوری در SSD (هنوز رمزگذاری نشده) .
بنابراین، احتمال دارد که این فایل دیسک نجات ممکن است به صورت صریح (توسط سخت افزار / سیستم عامل نرمافزاری SSD) به یک منطقه فیزیکی کپی شود که بعدا O / S قبل از فرایند رمزگذاری یا در طی آن دسترسی به آن ندارد در حال حاضر فکر می کنم: این اصل فایل نجات دیسک اجازه می دهد هر کسی که آن را داشته باشد رمزگشایی SSD، بدون در نظر گرفتن که اغلب رمز عبور رمزگذاری شده پس از آن تغییر کرده است و با توجه به رفتار استاندارد VC (ایجاد فایل دیسک نجات و قرار دادن آن در (در عین حال رمزگذاری نشده) درایو که برای رمزگذاری)، احتمال وجود دارد که این فایل دیسک نجات در فرم رمزنگاری به مناطق فیزیکی است که من هیچ دسترسی به هر گونه بیشتر، اما یک دشمن احتمالا دارد. [19659002] من به شدت امیدوارم که اشتباه کنم اگر نه، این کاملا دقیقا همان چیزی است که هر نرم افزار رمزنگاری باید در هر شرایطی اجتناب کند و وضعیت یک شکست فاجعه آمیز است که باید بلافاصله اصلاح شود. راه حل آسان خواهد بود:
VC نباید فایل دیسک نجات را هر گونه شرایطی ایجاد کند تا زمانیکه دیسک سیستم به طور کامل رمزگذاری نشود (دقیق تر: تا زمانی که VC کنترل کامل نداشته باشد همه درخواست ها را می نویسند، اطمینان حاصل کنید که هیچ اطلاعات رمزگذاری نشده تحت هر شرایطی نوشته شود).
حتی اگر بتوانید فایل دیسک نجات را به یک درایو دیگر ذخیره کنید (متاسفانه، نمی توانم به یاد داشته باشید که این امکان پذیر بود) احتمالا کافی نخواهد بود، حداقل تا زمانی که VC به نحوی نوشته شود که هرگز از فایلهای موقت استفاده نکند
من به شدت در مورد دوم شک دارم: با توجه به اینکه فایل دیسک نجات در فرمت ZIP است، به احتمال زیاد محتویات آن برای اولین بار به فایل های موقت منتقل می شود، احتمالا در دایرکتوری موقت O / S، که به نوبه خود روی فایل زیپ شده و در نهایت به مقصد انتخاب شده توسط کاربر نوشته می شود. این بدان معنی است که فایل دیسک نجات احتمالا در قالب خام در پارتیشن سیستم (با این حال رمزگذاری نشده) ذخیره می شود، قبل از اینکه فرم آخر آن (ZIP) در جاهای دیگر نوشته شود.
من نمی توانم وضعیت دیگری را که در آن امیدوار بودم به یاد بیاورم من یک خیمه کامل هستم بنابراین، هر کس، لطفا به من ثابت کنید که (لزوما با استفاده از همان اصطلاح)!
توجه داشته باشید 1
گرچه صحبت در مورد SSD ها در اینجا، من آگاه است که همین مشکل با HDD های معمول وجود دارد. اما احتمال این که چیزی بد با SSD اتفاق بیافتد با توجه به میزان سفارش (در مقایسه با هارد دیسک های معمولی) به علت بارگذاری لباس و بیش از حد مقرر بالاتر است.
Note 2
در انجمن وراکریپت اما هیچ کس حتی پس از 3 روز واکنش نشان نداده است، بنابراین سوال من اینقدر احمقانه است که حتی لازم نیست پاسخ داده شود یا امنیت بیشتر نباشد. با این حال، احساس من این است که این یک مسئله فوری است، بنابراین من به شدت قوانینی را که من معمولا دنبال می کنم برمیدارم و از بین رفته اند.
