کلیدهای WireGuard روی ESP32: برای هر دستگاه یا یک کلید تعبیه‌شده؟

طرح، کلید خصوصی WireGuard را در یک آرایهٔ کاراکتری می‌گذارد و تونل کار می‌کند، به همین دلیل این پرسش دوباره مطرح می‌شود. تصمیمی که واقعاً باید بگیرید این نیست که «آیا این امن است»، بلکه «کدام یک از سه شرط بر این استقرار حاکم است». آن‌ها عبارت‌اند از: چه کسی می‌تواند دستگاه را فیزیکاً در دست بگیرد، خواندن فلش روی قطعهٔ شما چه چیزی به دست می‌دهد، و اینکه ناوگان یک کلید را شریک می‌شود یا هر دستگاه کلید خودش را دارد. به آن‌ها پاسخ دهید و طراحی خودش می‌آید، چون هر شرط هزینهٔ کلید لو رفته را عوض می‌کند، نه این واقعیت را که ممکن است لو برود.

کلید چه چیزی را مجاز می‌کند

WireGuard همتاها را با کلید عمومی احراز هویت می‌کند. سرور کلید عمومی هر همتا را به یک نشانی و یک AllowedIPs فهرست نگاشت می‌کند، پس کلید خصوصی است که به کارخواه اجازه می‌دهد ترافیک را از آن نشانی بفرستد.

همان ورودی تعیین می‌کند دستگاه به کدام مقصدها می‌رسد، پس کلید لو رفته شبکهٔ پشت تونل و نیز نشانی تونل را آشکار می‌کند.

شرط یکم: چه کسی می‌تواند دستگاه را در دست بگیرد

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

این شرط را پیش از دو شرط دیگر روشن کنید، چون بودجهٔ هر دو را تعیین می‌کند.

شرط دوم: خواندن فلش چه چیزی به دست می‌دهد

هر کس تصویر فلش را بخواند، کلیدی را که به‌صورت رشتهٔ عینی ذخیره شده بازیابی می‌کند، چه از راه اتصال اشکال‌زدایی، چه فایل به‌روزرسانی، چه نسخهٔ پشتیبان یا دستگاهی که برگردانده شده. رمزگذاری فلش هزینهٔ تخلیهٔ مستقیم را بالا می‌برد، و مستندات ESP-IDF توضیح می‌دهد این ویژگی برای یک قطعه و پیکربندی مشخص چه چیزی را پوشش می‌دهد. این کار کلید را زیر هر مدل حمله‌ای غیرقابل‌استخراج نمی‌کند و برای حالتی که دستگاه در دست است هیچ کاری نمی‌کند. آن را یک لایه بدانید که هزینه را عوض می‌کند، نه پاسخ.

پیش از ادعای یک ویژگی در بازبینی طراحی، مستندات پلتفرم را برای تراشه و پیکربندی دقیق خود بخوانید.

شرط سوم: استفادهٔ دوباره در ناوگان

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

اگر ناوگان پنج دستگاه روی میز کار باشد، شریک‌شدن یک کلید ممکن است معاملهٔ معقولی باشد. اگر پانصد دستگاه در میدان باشد، اصلاً معامله‌ای نیست.

الگوی ثبت‌نامی که کلید برای هر دستگاه را عملی می‌کند

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

این سرویس کوچکی است، و همین تفاوت میان ناوگانی است که می‌توانید حسابرسی کنید و ناوگانی که فقط می‌توانید دوباره فلش کنید.

زمان، نقاط پایانی و تصمیم

نمونه پیش از آغاز تونل زمان را همگام می‌کند، و این فراتر از TLS اهمیت دارد: دست‌دادن‌های WireGuard مُهر زمانی برای محافظت در برابر تکرار حمل می‌کنند، پس دستگاهی که با ساعت اشتباه بالا بیاید ممکن است دست‌دادن‌های ردشده بگیرد. نقطهٔ پایانی یک نام میزبان است، که DNS را در مسیر اعتماد قرار می‌دهد، هرچند کلید عمومی سرور همچنان همتا را احراز هویت می‌کند. نشانی اشتباه تلاش‌ها را هدر می‌دهد و آشکار می‌کند دستگاه چه وقت آنلاین است. پیش از بحث دربارهٔ کلید، هر دو را حل کنید.

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