پرسش مفید امنیتی این نیست که رمزنگاری چقدر قدرتمند به نظر می‌رسد؛ بلکه این است که از چه چیزی محافظت می‌کند، کلیدها در اختیار چه کسی هستند و چه شواهدی از ادعا پشتیبانی می‌کنند.
«رمزنگاری در سطح نظامی» برای ارزیابی یک برنامهٔ پیام‌رسان اطلاعات کافی فراهم نمی‌کند. این عبارت نمی‌گوید کلیدها در اختیار چه کسی هستند، کدام گفت‌وگوها محافظت می‌شوند، آیا نسخه‌های پشتیبان متن آشکار را افشا می‌کنند یا هنگام نفوذ به یک دستگاه چه اتفاقی می‌افتد.
واکنش مفید، کنار گذاشتن رمزنگاری نیست؛ بلکه جایگزین کردن یک برچسب پرابهت با ادعاهای مشخص و قابل بررسی است.
AES-256 یک انتخاب الگوریتمی است، نه یک مدل امنیتی کامل
AES یک استاندارد عمومی است، نه فناوری نظامی محرمانه. استاندارد FIPS 197 مؤسسهٔ NIST الگوریتم‌های AES-128، AES-192 و AES-256 را مشخص می‌کند؛ پسوند آن‌ها طول کلید را نشان می‌دهد. این استاندارد در سال ۲۰۲۳ از نظر ویرایشی به‌روزرسانی شد، بدون آنکه الگوریتم تغییر کند.
یک رمز قوی همچنان ممکن است در سامانه‌ای استفاده شود که به سرویس امکان دسترسی به متن آشکار می‌دهد. فقط دربارهٔ طول کلید نپرسید؛ بپرسید چه کسی می‌تواند رمزگشایی کند. همچنین بپرسید کلیدها چگونه تولید و ذخیره می‌شوند، هویت‌ها چگونه احراز می‌شوند و در چه شرایط خطایی برنامه متوقف می‌شود، به‌جای آنکه به‌شکلی ناامن ادامه دهد.
وقتی یک عرضه‌کننده از AES-GCM نام می‌برد، نسبت به ذکر صرفِ AES اطلاعات دقیق‌تری ارائه می‌کند: GCM رمزنگاری را با اصالت‌سنجی ترکیب می‌کند. بااین‌حال، مدیریت درست نانس، بررسی برچسب اصالت و دیگر الزامات پیاده‌سازی همچنان اهمیت دارند. مشخصات GCM مؤسسهٔ NIST مرجع فنی است؛ یک نشان تجاری مدرک پیاده‌سازی درست آن در برنامه نیست.
چهار ادعای متفاوت که بازاریابی اغلب با هم ترکیب می‌کند
| ادعا | به چه چیزی می‌پردازد | چه چیزی را ثابت نمی‌کند |
|---|---|---|
| رمزنگاری حین انتقال | حفاظت در طول یک اتصال، مانند ارتباط برنامه با سرور | اینکه سرور نمی‌تواند محتوا را بخواند |
| رمزنگاری داده‌های ذخیره‌شده | حفاظت از داده‌های ذخیره‌شده در یک مدل مشخص کلید و دسترسی | اینکه بهره‌بردار کلید رمزگشایی را ندارد |
| رمزنگاری سرتاسری | حفاظت از محتوا میان نقاط پایانی مشخص | امنیت یک نقطهٔ پایانی نفوذشده یا درستکاری گیرنده |
| برقراری کلید پساکوانتومی | مقاومت در برابر تهدیدهای کوانتومی مشخص هنگام برقراری کلید | ممیزی کامل برنامه، ناشناس‌بودن یا تضمین امنیت آینده |
رمزنگاری حین انتقال به این معنا نیست که پایگاه دادهٔ همهٔ ارائه‌دهندگان متن آشکار خام ذخیره می‌کند. یک سرویس ممکن است داده‌های ذخیره‌شده را نیز رمزنگاری کند. تفاوت مهم این است که آیا ارائه‌دهنده کنترل کلیدها را دارد یا به شکل دیگری به محتوای خوانا دسترسی پیدا می‌کند. دقیق باشید، نه اینکه یک شعار را با شعاری دیگر جایگزین کنید.
برای آشنایی گسترده‌تر، به مطلب مربوط به دامنهٔ حفاظت رمزنگاری سرتاسری مراجعه کنید.
«استفاده از استاندارد NIST» به معنای «اعتبارسنجی‌شده بر اساس FIPS» نیست
FIPS 203 سازوکار کپسوله‌سازی کلید ML-KEM را تعریف می‌کند. یک پیام‌رسان می‌تواند استفاده از این الگوریتم را اعلام کند، بدون آنکه کل برنامه گواهی گرفته یا مستقلاً بررسی شده باشد. استانداردها، آزمون الگوریتم، اعتبارسنجی ماژول رمزنگاری و ممیزی امنیت محصول، انواع متفاوتی از شواهد هستند.
برنامهٔ اعتبارسنجی ماژول‌های رمزنگاری NIST روشن می‌کند که پیاده‌سازی توابع تأییدشده برای اثبات اعتبارسنجی ماژول بر اساس FIPS 140 کافی نیست. اگر محصولی اعتبارسنجی را تبلیغ می‌کند، گواهی، ماژول و نسخهٔ دقیق، محیط عملیاتی و پیکربندی تأییدشده را بخواهید. سپس مشخص کنید آن گواهی واقعاً کدام بخش محصول را پوشش می‌دهد.
به همین دلیل، «امنیت ۲۵۶ بیتی» نباید به‌عنوان امتیازی کلی برای تمام یک پیام‌رسان استفاده شود. ترکیب پروتکل‌ها، مدیریت کلید و پیاده‌سازی ممکن است محدودیت‌های متفاوتی ایجاد کنند.
احراز هویت با گذرواژه، رمزنگاری پیام نیست
سازوکار ورود پاسخ می‌دهد که آیا کاربر می‌تواند به یک حساب دسترسی داشته باشد. رمزنگاری سرتاسری پاسخ می‌دهد که چه کسی می‌تواند محتوای پیام محافظت‌شده را بخواند. هیچ‌کدام به‌طور خودکار ویژگی‌های دیگری را فراهم نمی‌کند.
برای نمونه، SRP برای احراز هویت بدون ارسال خود گذرواژه طراحی شده است. این به معنای بی‌خطر بودن سرقت پایگاه دادهٔ احراز هویت نیست. بحث امنیت SRP در RFC 5054 توضیح می‌دهد که سرقت مقدار وارسی‌گر امکان حملات حدس‌زدن گذرواژه و خطرهای دیگری را فراهم می‌کند. از نتیجه‌گیریِ «گذرواژه‌ای برای سرقت وجود ندارد، پس نفوذ به سرور اهمیتی ندارد» پرهیز کنید.
برای خواننده، پیگیری عملی این است که دربارهٔ بازیابی حساب، نشست‌های فعال و رابطهٔ دسترسی به حساب با کلیدهای رمزنگاری بپرسد. پاسخی که فقط «دانش صفر» را تکرار می‌کند، پرسش‌های مهم را بی‌پاسخ می‌گذارد.
پنج پرسش برای سنجش صفحهٔ امنیت یک پیام‌رسان
- کدام بخش‌ها پوشش داده می‌شوند؟ گفت‌وگوی مستقیم، گروه، فایل، تماس، نوشته‌های عمومی و نسخه‌های پشتیبان ممکن است مرزهای متفاوتی داشته باشند.
- کلیدهای قابل استفاده در اختیار چه کسی هستند؟ کلیدهای بازیابی، دستگاه‌های پیوندخورده و حالت‌های پردازش در سمت سرور را نیز در نظر بگیرید.
- هویت نقطهٔ پایانی دیگر چگونه احراز می‌شود؟ به‌دنبال بررسی کلید، هشدارهای معنادار تغییر و یک مدل اعتماد مستند باشید.
- چه شواهدی وجود دارد؟ مشخصات فنی، ساخت‌های بازتولیدپذیر، بردارهای آزمون و ممیزی‌های مستقل به پرسش‌های متفاوتی پاسخ می‌دهند. نسخه و دامنهٔ هرکدام را بپرسید.
- چه چیزهایی همچنان قابل مشاهده یا آسیب‌پذیرند؟ فراداده، دستگاه‌های نفوذشده، پیام‌های کپی‌شده و محتوای عمومی نباید از توضیح حذف شوند.
همین آزمون را برای Livara نیز به کار ببرید. مستندات امنیتی آن از LVR1 و LGS1 نام می‌برد و مرزهای عملیاتی را منتشر می‌کند. این‌ها را ادعاهای محصول بدانید که باید ارزیابی شوند، نه گواهی مستقل. Proof Lab نمایش‌های محدود و بررسی خروجی‌های نرم‌افزاری را ارائه می‌کند، نه اثبات امنیت تمام قابلیت‌ها یا نسخه‌ها.
چگونه یک ممیزی مستقل را بخوانیم
تاریخ، ممیز، بازبینی کد، پلتفرم‌های مشمول و اجزای خارج از دامنه را بررسی کنید. یافته‌ها و وضعیت رفع آن‌ها را بخوانید، نه فقط نشان خلاصه را. ممیزی یک کتابخانهٔ رمزنگاری به‌طور خودکار بازیابی حساب، برنامهٔ وب، اعلان‌ها یا امنیت عملیاتی را پوشش نمی‌دهد.
نبود ممیزی، شکافی در پشتوانهٔ اطمینان است، نه اثبات یک آسیب‌پذیری مشخص. از سوی دیگر، ممیزی تضمینی مادام‌العمر نیست. مقایسهٔ مفید شواهد و محدودیت‌هایشان را ثبت می‌کند، به‌جای آنکه برنده‌ای همیشگی با عنوان «امن‌ترین» اعلام کند.
پرسش‌های متداول
آیا «در سطح نظامی» همیشه نام دیگری برای AES-256 است؟
خیر. از این عبارت، الگوریتم یا گواهی مشخصی را استنباط نکنید. از عرضه‌کننده بخواهید دقیقاً توضیح دهد منظورش چیست.
آیا رمزنگاری قوی‌تر جلوی اسکرین‌شات یا بدافزار را می‌گیرد؟
این رمزنگاری جلوی کپی‌کردن محتوا توسط گیرنده یا افشای داده‌های قابل دسترس توسط یک دستگاه نفوذشده را نمی‌گیرد. این‌ها تهدیدهای متفاوتی هستند.
چه نشانه‌ای از یک شعار امنیتی بهتر است؟
دامنهٔ روشن، پروتکلی با نام مشخص، محدودیت‌های صریح و شواهد قابل بررسی دربارهٔ پیاده‌سازی عرضه‌شده. توضیح باید کمک کند تصمیم بگیرید به چه چیزی اعتماد کنید و چه چیزی هنوز نیاز به بررسی دارد.
