یک گواهی برای هر دستگاه، کلید را به دستگاه پیوند نمی‌دهد
گواهی برای هر دستگاه یک انتخاب مدیریتی است، نه پیوند با دستگاه. آنچه پیوند را تعیین می‌کند جای زندگی کلید خصوصی است، از یک فایل قابل کپی تا یک TPM.
برای هر لپ‌تاپ یک گواهی جداگانه صادر می‌کنید، پس فرض می‌کنید VPN می‌تواند آن‌ها را از هم تشخیص دهد. نمی‌تواند. گواهی مشتری اثبات می‌کند که هر کس متصل می‌شود کلید خصوصی مطابق را دارد، و پروفایل کپی‌شده هم آن را دارد.
گواهی برای هر دستگاه هنوز ایده خوبی است. فقط کاری متفاوت از آنچه بیشتر مردم انتظار دارند انجام می‌دهد.
گواهی مشتری در واقع چه چیزی را اثبات می‌کند
در هنگام دست‌دادن، مشتری با کلید خصوصی مطابق گواهی‌اش امضا می‌کند و سرور آن امضا را در برابر CA که به آن اعتماد دارد بررسی می‌کند. هیچ چیز در این تبادل ماشین را توصیف نمی‌کند. هر دستگاهی که هم گواهی و هم کلید را داشته باشد امضای یکسانی تولید می‌کند، بنابراین پروفایلی که به لپ‌تاپ دومی کپی شده است دقیقاً مانند نسخه اصلی به نظر می‌رسد. گواهی یک هویت را نام می‌برد؛ سخت‌افزار را نام نمی‌برد.
یگانگی هر دستگاه هنوز ارزش دارد، چون ابطال را دقیق می‌کند. این یک ویژگی مدیریتی است، نه قفل فنی.
سه سطح ذخیره‌سازی کلید
سطح اول یک فایل کلید روی دیسک است. طبق طراحی قابل حمل است و بیشتر پروفایل‌های OpenVPN همان‌جا زندگی می‌کنند.
سطح دوم کلیدی است که سیستم‌عامل آن را غیرقابل صدور علامت می‌زند. ویندوز می‌تواند کلید دستگاه را در مخزن گواهی خود تولید کند و از صدور معمولی خودداری کند، که از کپی اتفاقی جلوگیری می‌کند. این کلید پشتوانه سخت‌افزاری ندارد و با دسترسی کافی به ماشین می‌توان چنین کلیدهایی را بازیابی کرد، پس تلاش را بالا می‌برد نه اینکه دیواری بسازد.
سطح سوم کلیدی است که درون سخت‌افزار امنیتی تولید می‌شود: TPM، کارت هوشمند، SIM یا توکن PIV. این ماژول‌ها مدار لازم برای صدور کلیدی که تولید کرده‌اند را ندارند و امضا درون ماژول انجام می‌شود. کلید هرگز به فایلی تبدیل نمی‌شود که کسی بتواند کپی کند.
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
آن جدول تمام استدلال در سه ردیف است.
easy-rsa چه می‌تواند بکند و چه نمی‌تواند
صدور گواهی برای هر دستگاه ساده است. برای هر دستگاه یک نام مشترک جداگانه در برابر همان CA بسازید، مثلاً ./easyrsa build-client-full laptop-a nopass، و برای هر دستگاه تکرار کنید. ثبت کنید کدام نام مشترک به کدام شخص و ماشین تعلق دارد.
ابطال هم به همان اندازه مستقیم است: ./easyrsa revoke laptop-a، CRL را با ./easyrsa gen-crl دوباره تولید کنید و مطمئن شوید سرور واقعاً آن را از طریق crl-verify می‌خواند.
آنچه CA نمی‌تواند انجام دهد بررسی این است که کلید خصوصی بعداً کجا زندگی می‌کند. اگر کلید را روی میزبان CA تولید کنید و به دستگاه کپی کنید، هنگام صدور نسخه دومی ساخته‌اید. کلید غیرقابل صدور باید روی دستگاه تولید شود یا به سخت‌افزاری وارد شود که آن را آزاد نمی‌کند.
کنترل‌هایی که در برابر پروفایل کپی‌شده دوام می‌آورند
فرض کنید پروفایل می‌تواند کپی شود و بر همین اساس طراحی کنید. حساب را به یک عامل دوم گره بزنید تا گواهی به‌تنهایی کافی نباشد. به هر دستگاه سیاست خودش را بدهید تا دامنه یک هویت محدود بماند. و مراقب همان نام مشترکی باشید که هم‌زمان از دو نشانی متصل می‌شود، چون پروفایل اشتراکی در گزارش اتصال همین‌طور به نظر می‌رسد.
ابطال سریع و مستند همان کنترلی است که پس از رخ دادن کپی هم کار می‌کند. بقیه چیزها پیشگیری است.
ادعایی که سرور واقعاً می‌تواند بر آن تکیه کند
یگانگی از CA می‌آید. پیوند با دستگاه از ذخیره‌سازی کلید می‌آید. تنها سخت‌افزاری که نمی‌تواند کلیدش را صادر کند، یک گواهی برای هر دستگاه را به ادعایی تبدیل می‌کند که سرور اعمال می‌کند، نه سیاستی که همه موافقت می‌کنند از آن پیروی کنند.