حذف یک نفر از گروه رمز‌شده باید مانع دریافت اسراری شود که برای پیام‌های محافظت‌شدهٔ آینده لازم‌اند. اگر فرستندگان باقی‌مانده همچنان از مواد کلیدی استفاده کنند که عضو سابق از قبل می‌داند، صرف تغییر فهرست اعضا این هدف را محقق نمی‌کند.
این گذار در سراسر یک شبکهٔ نامطمئن نیز آنی نیست. طراحی امن گروه باید مشخص کند هر پیام به کدام وضعیت عضویت تعلق دارد و فرستنده پیش از پردازش حذف چه کاری انجام می‌دهد.
پیام‌های گذشته و آینده دو مسئلهٔ متفاوت‌اند
عضو سابق ممکن است پیام‌ها، فایل‌ها و کلیدهایی را که هنگام داشتن مجوز دریافت کرده، نگه دارد. حذف نمی‌تواند او را وادار کند تاریخچه را فراموش کند یا اسکرین‌شات‌هایش را پاک کند.
هدف دست‌یافتنی این است که او از وضعیت رمزنگارانهٔ جدید پس از مؤثر شدن حذف کنار گذاشته شود. به همین ترتیب، افزودن یک نفر پرسشی جداگانه ایجاد می‌کند: آیا به تاریخچهٔ قدیمی دسترسی می‌یابد؟ محصولات و پروتکل‌ها اصطلاحاتی مانند محرمانگی پیشرو را در زمینه‌های متفاوت به کار می‌برند؛ بنابراین شرح سادهٔ قاعدهٔ دسترسی موردنظر اغلب روشن‌تر از برچسبی مبهم است.
چرا گروه‌های دارای کلید فرستنده به وضعیت تازه نیاز دارند؟
در طراحی مبتنی بر کلید فرستنده، هر شرکت‌کننده می‌تواند پیام‌های عادی گروه را با زنجیره‌ای رمز کند که با گیرندگان مجاز مشترک است. این کار می‌تواند نیاز به رمزکردن جداگانهٔ کل محتوا برای تک‌تک گیرندگان در هر ارسال را برطرف کند.
پس از حذف، عضو سابق ممکن است همچنان زنجیرهٔ قدیمی را داشته باشد. بنابراین فرستندگان باقی‌مانده به وضعیت جایگزینی نیاز دارند که به عضو حذف‌شده توزیع نشود و کلاینت‌ها برای استفاده از آن به زمینهٔ عضویت موردتوافق نیاز دارند. تعویض کلید باید فرستندگان و دستگاه‌های مرتبط را پوشش دهد؛ تغییر یک پرچم سمت سرور کافی نیست.
پروتکل دقیق اهمیت دارد. MLS که در RFC 9420 مشخص شده است، حذف را از طریق تغییر تثبیت‌شدهٔ دوره مدیریت می‌کند که آنتروپی تازه‌ای به اعضای باقی‌مانده می‌رساند. این نمونه‌ای از گذار وضعیت تعریف‌شده است، نه ادعایی مبنی بر اینکه لیوارا MLS را پیاده‌سازی می‌کند.
لیوارا دربارهٔ LGS1 چه مستند کرده است؟
صفحهٔ امنیت لیوارا برای هر فرستنده یک زنجیرهٔ فرستندهٔ امضاشده را توضیح می‌دهد که کلیدهای آن از طریق نشست‌های دوتایی LVR1 توزیع می‌شوند. این صفحه می‌گوید هنگام تغییر عضویت، کلیدهای تازهٔ فرستنده ساخته و توزیع می‌شوند.
این موضوع از ادعایی دربارهٔ طراحی منتشرشدهٔ تعویض کلید پشتیبانی می‌کند. اما زمان اندازه‌گیری‌شده‌ای برای «لغو آنی دسترسی» تعیین نمی‌کند و ثابت نمی‌کند همهٔ وضعیت‌های رقابتی، سناریوهای دستگاه آفلاین و تلاش‌های مجدد درست مدیریت می‌شوند. این‌ها به تحلیل پیاده‌سازی و آزمایش نیاز دارند.
کنترل عضویت سمت سرور و کنارگذاری رمزنگارانه نیز وظایف متفاوتی دارند. سرویس می‌تواند تحویل یا دسترسی را رد کند، درحالی‌که رمزنگاری باید مانع شود طرف حذف‌شده‌ای که نسخه‌ای از متن رمز‌شدهٔ بعدی را دارد، بدون اسرار جدید آن را باز کند.
برنامه‌ای مفید برای آزمایش حذف
در یک گروه آزمایشی که مجوز آزمودنش را دارید، این سناریوها را با پیام‌های غیرحساس بررسی کنید:
| سناریو | پرسشی که باید پاسخ داده شود |
|---|---|
| حذف عضو زمانی که همه آنلاین‌اند | کدام پیام نخستین پیام تحت وضعیت عضویت جدید است؟ |
| یکی از فرستندگان باقی‌مانده آفلاین است | آیا پیش از ارسال دوباره باید عضویت و کلیدها را تازه کند؟ |
| عضو حذف‌شده بعداً دوباره متصل می‌شود | آیا توزیع‌های جدید کلید فرستنده را دریافت می‌کند یا فقط محتوای قدیمیِ مجاز را؟ |
| چند عضو هم‌زمان تغییر می‌کنند | آیا همهٔ دستگاه‌های باقی‌مانده به وضعیت یکسان می‌رسند؟ |
| ارسال یک پیام قدیمی دوباره امتحان می‌شود | آیا دورهٔ اصلی آن حفظ می‌شود یا به‌اشتباه محتوای جدید برچسب می‌خورد؟ |
آزمایش صرفاً از طریق رابط کاربری می‌تواند رفتار قابل‌مشاهده را تأیید کند، اما به‌تنهایی کنارگذاری رمزنگارانه را ثابت نمی‌کند. ارزیابی دقیق باید بررسی کند دستگاه آزمایشیِ حذف‌شده چه کلیدها و متن‌های رمز‌شده‌ای می‌تواند به دست آورد.
مدیران چه چیزی را باید به خاطر بسپارند؟
شرکت‌کنندگان غیرضروری را حذف کنید، اعضای باقی‌مانده را مرور کنید و تا زمانی که برنامه تغییر را پردازش نکرده، محتوای حساس تازه نفرستید. اگر یک عضو فعلی عمداً محتوا را فوروارد کند، تعویض کلید گروه نمی‌تواند مانع این افشا شود.
برای کاربردهای بسیار حساس، قواعد دقیق حذف، رفتار لغو مجوز دستگاه و شواهد آزمایش را از ارائه‌دهنده بخواهید. وعدهٔ مهم، مرزی روشن برای پیام‌های آینده است، نه ادعایی بی‌پشتوانه که دکمهٔ حذف همهٔ نسخه‌های گذشته را نابود می‌کند.
