اولویت فشرده‌سازی و رمزنگاری

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

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

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

حال با در نظر گرفتن دو گزاره‌ی بالا، اولین جوابی که به سوال ابتدایی متن به ذهن خواهد رسید این است که

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

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

1. ابتدا فشرده‌سازی و سپس رمزنگاری
2. عدم استفاده از فشرده‌سازی و تنها اکتفا به رمزنگاری

مشکل امنیتی

فرض کنید در میان مسیر میان دو رایانه که از طریق پروتکل ما با هم ارتباط برقرار می‌کنند، یک هکر قرار گرفته است و داده‌های رمزشده‌ی تبادلی را مشاهده می‌کند. در ساده‌ترین حالت هکر قادر است با مشاهده‌ی حجم بسته‌های رمزشده‌ی تبادلی به اطلاعاتی کلی از حجم پیام اصلی (رمزنشده) تبادلی دست یابد. این اطلاعات کلی، اگر با جزئیاتی از پیام‌های اصلی همراه شوند، می‌توانند حتی کلّ فرایند رمزنگاری را بی‌اثر کنند. باز هم به عنوان یک مثال خیلی خیلی ساده فرض کنید که رایانه‌ها تنها به یکدیگر تنها پیام‌های YES و NO ارسال می‌کنند و فرض کنید الگوریتم رمزنگاری به گونه‌ای باشد که رمزکردن YES منجر به تولید یک Ciphertext با طول 9 کاراکتر و رمزکردن NO منجر به تولید یک Ciphertext با طول 6 شود. در این صورت مهاجم بدون داشتن کلید و تنها با داشتن طول بسته‌های تبادلی می‌تواند به محتوای پیام‌ها دست یابد. این مسئله در الگوریتم‌های رمزنگاری، در بسیاری موارد اگر با الگوریتم‌های فشرده‌ساز همراه شوند، منجر به افشای اطلاعات بیشتری از پیام اصلی می‌شوند. به عبارت دیگر در مواردی که طراح پروتکل پیش از ارسال داده‌ها، آن‌ها را فشرده کند، اگر دقت کافی به خرج نداده باشد، به احتمال زیاد، کار استخراج اطلاعات کلی از داده‌های رمز شده را برای مهاجم ساده‌تر کرده است. به عنوان یک مثال از این کم دقتی، سیستمی را تصور کنید که پیام مهاجم به عنوان یک کاربر سامانه همراه پیام کاربر دیگری فشرده و سپس رمز و ارسال می‌شود. فرض کنید سیاست سامانه بر این است که هیچ کدام از کاربران نباید از پیام دیگر کاربران مطلع شوند:

در این طراحی، مهاجم (که یک کاربر سامانه است) می‌تواند با تولید ورودی‌های مختلف برای ماژول فشرده‌کننده و مشاهده‌ی سایز خروجی، به اطلاعاتی از پیام کاربر دیگر ارسال دست یابد. مثلا اگر اطلاع داشته باشد پیام کاربر دیگر یا AAAA و یا BBBB است، می‌تواند با فرستادن AAAA و مشاهده‌ی طول خروجی متوجه شود که آیا خروجی فشرده‌ساز نسبت به ورودی خیلی کمتر بوده (که یعنی پیام کاربر دیگر هم AAAA بوده و بنابراین داده‌ها خیلی فشرده شده اند) و یا متوجه شود که طول خروجی فشرده ساز نسبت به ورودی خیلی کمتر نیست (که یعنی پیام کاربر دیگر BBBB بوده و بنابراین داده‌ها خیلی فشرده نشده‌اند.

چقدر این حملات جدی هستند و راه حل چیست؟

متاسفانه علی‌رغم ظاهر پیچیده و غیر عملی این حملات، در دنیای امنیت و دنیای رمزنگاری و ریاضیات، این حملات خیلی تخیلی نیستند و هر از چندی یک رخنه‌ی امنیتی بر اساس این نقاط ضعف، در پروتکل‌های معروف کشف و معرفی می‌شود. در صورتی که علاقمند به نمونه‌های واقعی این حملات هستید، مطالعه‌ حمله‌ی CRIME که یک آسیب‌پذیری روی نسخه‌های قدیمی SSL/TLS را هدف قرار داد و همچنین مطالعه‌ی مقاله‌ Phonotactic Reconstruction of Encrypted VoIP Conversations که در آن تلاش شده است با چنین تکنیکی، صوت را از ترافیک‌های VoIP رمزشده استخراج کند، برای شما جذاب خواهد بود. راه حل پیش‌گیری از این حملات و آسیب‌پذیری‌ها این است که حتی‌الامکان تا زمانی که مشکل Performance نداریم و تا زمانی که به درستی فرآیندهای پیاده‌سازی شده اطمینان نداریم، در عملیات‌های رمزنگاری از فشرده‌سازی استفاده نکنیم و داده‌ها را مستقیم رمز کرده و ارسال کنیم.

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