مرورگر می‌تواند رمزنگاری قدرتمند اجرا کند؛ اما کدی که به مرورگر تحویل می‌شود همچنان باید قابل اعتماد باشد.
مرورگر می‌تواند بدون نصب برنامهٔ پیام‌رسان بومی، رمزگذاری سرتاسری را به‌صورت محلی انجام دهد؛ از جمله برقراری کلید پساکوانتومی. پرسش دشوار این نیست که آیا محاسبات ریاضی در یک زبانه اجرا می‌شوند یا نه. مسئله این است که آیا برنامهٔ تحویل‌داده‌شده، نحوهٔ مدیریت کلید و مسیر به‌روزرسانی، شایستهٔ اعتمادی هستند که آن گفت‌وگو نیاز دارد.
وقتی نصب برنامه ممکن نیست، دسترسی تحت وب می‌تواند راحت باشد. اما این راحتی برنامه را در برابر سانسور، میزبانیِ به‌خطر‌افتاده، افزونه‌های مخرب یا دستگاه آلوده مصون نمی‌کند.
اجزای پایهٔ رمزنگاری در مرورگر
WebCrypto عملیات سطح پایین برای رمزگذاری، مشتق‌سازی کلید، امضا و مدیریت کلید را در اختیار می‌گذارد. پیاده‌سازی‌های رایج، اجزای پایه‌ای مانند AES-GCM و ECDH دارند. این عملیات، مصالح ساخت هستند، نه یک پروتکل کامل پیام‌رسانی با احراز اصالت.
هرجا API بومیِ مورد نیاز موجود نباشد، برنامهٔ وب می‌تواند یک پیاده‌سازی بازبینی‌شدهٔ ML-KEM را با JavaScript یا WebAssembly اضافه کند. پشتیبانی مرورگرها تغییر می‌کند؛ بنابراین توسعه‌دهندگان باید قابلیت‌ها را در نسخه‌های دقیقِ هدف آزمایش کنند، نه اینکه فرض کنند همهٔ مرورگرها الگوریتم‌های یکسانی ارائه می‌دهند.
یک جریان ترکیبی در سطح مفهومی چنین است:
- کلیدهای مناسب را با تصادفی‌بودنِ امن از نظر رمزنگاری تولید کنید.
- اصالت مواد کلیدیِ طرف مقابل را با سازوکار هویتِ پروتکل بررسی کنید.
- سهم‌های راز مشترکِ کلاسیک و پساکوانتومی را به دست آورید.
- آن‌ها را با استفاده از برنامهٔ مشتق‌سازی کلیدِ مشخص‌شده و زمینهٔ گفت‌وگو ترکیب کنید.
- با مدیریت صحیح nonce و وضعیت، از کلیدهای مشتق‌شده برای رمزگذاریِ احرازشده استفاده کنید.
این فقط طرحی توضیحی است، نه دستور پیاده‌سازی. FIPS 203 استاندارد ML-KEM را تعریف می‌کند؛ نه یک برنامهٔ مرورگری خاص را تأیید می‌کند و نه همهٔ مراحل پروتکل چت را مشخص می‌سازد.
تحویل از طریق HTTPS بخشی از مدل اعتماد است
معمولاً سرور، JavaScript و WebAssembly را که قرار است متن آشکار را پردازش کنند، فراهم می‌کند. برنامه‌ای که با نیت مخرب تغییر کرده باشد می‌تواند پیام را پیش از رمزگذاری یا پس از رمزگشایی بخواند، حتی اگر کتابخانهٔ رمزنگاری آن از الگوریتم‌های معتبر استفاده کند.
HTTPS به احراز اصالت مبدأ تحویل و محافظت از تحویل در برابر دخالت شبکه کمک می‌کند. اما ثابت نمی‌کند که گردانندهٔ مبدأ، سامانهٔ استقرار یا وابستگی‌های آن به خطر نیفتاده‌اند. یک صفحهٔ معمولی HTTPS خودبه‌خود یک بستهٔ برنامه با امضای مستقل نیست.
ملاحظات امنیتی WebCrypto در W3C به تزریق اسکریپت و ضرورت محافظت از یکپارچگی برنامه می‌پردازد. سیاست امنیت محتوا، مدیریت دقیق وابستگی‌ها و دیگر کنترل‌های امنیت وب خطر را کاهش می‌دهند، اما هیچ‌کدام یک اسکریپت دلخواهِ هم‌مبدأ را به ناظری نامطمئن تبدیل نمی‌کنند که نتواند به داده‌های برنامه دست بزند.
WebAssembly نیز در مرز امنیتی همان برنامه قرار دارد. محیط ایزولهٔ آن، دسترسی به میزبان را به رابط‌های تعریف‌شده محدود می‌کند؛ اما صفحهٔ فراخواننده را قابل اعتماد نمی‌کند. کامپایل C به Wasm، زبان مبدأ را از نظر حافظه ایمن نمی‌سازد.
کلیدها لزوماً فقط در RAM نیستند
پیام‌رسان مرورگری ممکن است کلیدها یا وضعیت رمزگذاری‌شده را به‌طور پایدار نگه دارد تا کاربر بتواند با همان هویت بازگردد. همچنین ممکن است پیوند دستگاه یا بازیابی رمزگذاری‌شده ارائه دهد. این رفتارها باید مستند شوند، نه اینکه وجودشان را با فرض نادیده بگیریم.
پرسش‌های مهم عبارت‌اند از:
- کدام کلیدها به‌طور پایدار ذخیره می‌شوند و در کدام فضای ذخیره‌سازی مرورگر؟
- با پاک‌شدن داده‌های سایت یا پایان نشست مرور خصوصی چه اتفاقی می‌افتد؟
- آیا کد مخربی که در زمینهٔ برنامه اجرا می‌شود همچنان می‌تواند از کلید غیرقابل‌استخراج استفاده کند؟
- آیا یک به‌روزرسانی تازه‌تحویل‌داده‌شده می‌تواند به وضعیت محلیِ قدیمی دسترسی پیدا کند؟
- بازیابی، هویت را برمی‌گرداند، تاریخچهٔ پیام‌ها را، یا هر دو را؟
کلید غیرقابل‌استخراجِ WebCrypto، خروجی‌گرفتن از طریق API را محدود می‌کند. این ویژگی به‌تنهایی جلوی درخواست عملیات مجاز یا جمع‌آوری متن آشکار توسط کد خصمانهٔ برنامه را نمی‌گیرد.
کلاینت‌های وب و بومی بده‌بستان‌های متفاوتی دارند
| موضوع | کلاینت مرورگری | کلاینت بومی |
|---|---|---|
| توزیع | مبدأ، میزبانی و زنجیرهٔ به‌روزرسانی وب | فروشگاه برنامه یا زنجیرهٔ توزیع و امضای بسته |
| ماندگاری محلی | ذخیره‌سازی مرورگر و رفتار پروفایل | ذخیره‌سازی برنامه در سیستم‌عامل و چرخهٔ عمر برنامه |
| سطح مواجهه | اسکریپت‌های هم‌مبدأ، افزونه‌ها و آسیب‌پذیری‌های مرورگر | وابستگی‌های برنامه و آسیب‌پذیری‌های سیستم‌عامل یا برنامه |
| دسترس‌پذیری | دامنهٔ قابل دسترسی و خدمات شبکهٔ مورد نیاز | برنامهٔ نصب‌شده همچنان به خدمات شبکهٔ مورد نیاز خود وابسته است |
بدون بررسی پیاده‌سازی، هیچ‌یک از دو ستون برنده‌ای تعیین نمی‌کند. یک برنامهٔ وب ممکن است پس از حذف از فروشگاه برنامه همچنان در دسترس باشد، اما مسدودشدن دامنه یا نبود مسیر شبکه باز هم می‌تواند مانع دسترسی شود.
عملکرد را اندازه بگیرید، نه اینکه وعده بدهید
طبق FIPS 203، ML-KEM-768 از کلید کپسوله‌سازیِ 1,184 بایتی و متن رمزِ 1,088 بایتی استفاده می‌کند. این اندازه‌ها کمک می‌کنند بفهمیم چرا پروتکل‌ها ممکن است به‌روزرسانی‌های KEM را زمان‌بندی کنند، نه اینکه به هر پیام کوتاه مواد تازه‌ای بچسبانند. این‌ها اندازه‌گیری پهنای باند یا سرعت کل برنامه نیستند.
یک بنچمارک مفید، مرورگر، دستگاه، نسخهٔ ساخت، روش گرم‌کردن، عملیات اندازه‌گیری‌شده و توزیع زمان‌ها را مشخص می‌کند. راه‌اندازی صفحه، بارگذاری ماژول، مصرف حافظه، دستگاه‌های ضعیف و سربار شبکه را هم در نظر بگیرید. ادعاهایی مانند «زیر دو میلی‌ثانیه روی همهٔ گوشی‌های امروزی» به اندازه‌گیری‌های منتشرشده نیاز دارند؛ این مقاله چنین داده‌هایی ارائه نمی‌کند.
کاربرد این نکات برای Livara
مرور امنیتی لیوارا، LVR1 و مرزهای بازیابی آن را مستند می‌کند. Proof Lab برخی عملیات محلی P-256، HKDF و AES-GCM را نمایش می‌دهد؛ این صفحه صریحاً ترکیب کامل LVR1/LGS1 را خارج از محدودهٔ آن آزمون قرار می‌دهد. بنابراین موفقیت نمایش، امنیت تمام کد وبِ عرضه‌شده را ثابت نمی‌کند.
پیش از یک گفت‌وگوی حساس در مرورگر، از کلاینت اصیل و نگه‌داری‌شده استفاده کنید، مدل تهدید فعلی را بخوانید، از پروفایل مرورگر محافظت کنید و طرف مقابل را با فرایند پشتیبانی‌شدهٔ بررسی کلید تأیید کنید. راحتی و رمزنگاری مفید می‌توانند کنار هم باشند، به شرط آنکه مرز تحویل وب همچنان بخشی از ارزیابی بماند.
