بنیاد لینوکس، BastionZero و Docker از یک پروژه متنباز جدید به نام OpenPubKey رونمایی کردهاند که پروتکل رمزنگاری با همین نام را برای امضای دیجیتالی اشیاء دلخواه توسعه میدهد. این فناوری به عنوان یک پروژه مشترک بین BastionZero و Docker توسعه داده شده است تا امضای دیجیتالی تصاویر کانتینر Docker را سادهتر کند، از دستکاری جلوگیری کند و تأیید کند که این ساخت توسط سازنده اصلی ایجاد شده است. این پروژه بر روی یک پلتفرم بیطرف تحت نظارت بنیاد لینوکس توسعه داده خواهد شد، وابستگی به شرکتهای تجاری فردی را از بین میبرد و همکاری با مشارکتکنندگان شخص ثالث را تسهیل میکند. پیادهسازی مرجع OpenPubKey با زبان Go نوشته شده و تحت مجوز Apache 2.0 است.
قابلیتهای OpenPubKey محدود به تصاویر کانتینر نیست؛ این فناوری میتواند برای تأیید منبع هر منبعی، جلوگیری از جعل وابستگی و بهبود امنیت کانالهای توزیع دادهها مورد استفاده قرار گیرد. به عنوان مثال، این فناوری میتواند برای تأیید ساخت نرمافزار، پیامهای فردی و کامیتها استفاده شود. ایجادکنندگان امضا فقط به یک حساب کاربری با یک سرویس فعالشده با OpenID نیاز دارند، در حالی که مصرفکنندگان میتوانند امضاهای پیوستشده را تأیید کرده و ارتباط آنها را با شناسه OpenID اعلامشده تأیید کنند.
OpenPubKey از نظر هدف، شبیه به سیستم Sigstore است که توسط گوگل ایجاد شده و قبلاً به بنیاد لینوکس منتقل شده است، اما با آن تفاوت دارد زیرا با حذف اجزای سرور متمرکز که مسئول نگهداری یک گزارش عمومی برای تأیید صحت تغییرات (گزارش شفافیت) و اطمینان از عملکرد مراجع صدور گواهینامه (مرجع صدور گواهینامه) هستند، پیادهسازی، استفاده و نگهداری را به طور قابل توجهی ساده میکند.
به جای استقرار CA های سفارشی، OpenPubKey از احراز هویت OpenID استفاده میکند و امضاهای تولید شده را به ارائه دهندگان موجود OpenID Connect متصل میکند. به عبارت دیگر، OpenPubKey به شما امکان میدهد کلیدهای رمزنگاری را به کاربران خاص با استفاده از ارائه دهندگان OpenID Connect (IdPs) به جای CA ها متصل کنید. این فناوری کاملاً با ارائه دهندگان موجود OpenID مانند GitHub، Azure/Microsoft، Okta، OneLogin، Keycloak و Google سازگار است و نیازی به تغییر در آن ارائه دهندگان ندارد (از یک توکن شناسایی استاندارد ارائه شده توسط ارائه دهنده استفاده میکند و به OpenPubKey اجازه میدهد فقط از طریق تغییرات در کلاینت OpenID Connect پیادهسازی شود).
توکن صادر شده توسط ارائه دهنده OpenID به یک گواهی تبدیل میشود که به صورت رمزنگاری، شناسه OpenID Connect را به کلید عمومی متصل میکند. سپس کاربر از کلید تولید شده برای امضای هرگونه داده استفاده میکند و این امضاها بعداً میتوانند در برابر شناسه OpenID Connect تأیید شوند. OpenPubKey از کلیدهای موقت با طول عمر محدود استفاده میکند - کلیدها در طول ورود به OpenID تولید میشوند و پس از پایان جلسه با ارائه دهنده OpenID حذف میشوند.
یک الگوریتم تقریبی برای ایجاد امضا با استفاده از OpenPubKey:
- با استفاده از یک ارائهدهنده OpenID (گوگل، گیتهاب، مایکروسافت و غیره) وارد شوید.
- از یک ارائه دهنده OpenID، یک توکن شناسایی درخواست کنید.
- یک توکن امضا شده با کلید ارائه دهنده و شامل یک فیلد "nonce" با دادههای دلخواه منتقل شده در طول درخواست (هش SHA3 کلید عمومی منتقل میشود) را برگردانید.
- استفاده از توکن دریافتی در سمت کاربر به عنوان گواهی که شامل اطلاعات کلیدی است.
- اتصال یک توکن به امضا، مشابه گواهی.
تأیید شامل بررسی این است که آیا توکن پیوست شده توسط ارائهدهنده OpenID امضا شده است یا خیر و همچنین تأیید اعتبار امضای دیجیتال روی منبع با استفاده از کلید عمومی. این امر تأیید میکند که منبع با استفاده از شناسه موجود در گواهی امضا شده است و این موضوع توسط امضای ارائهدهنده OpenID تأیید میشود. به عنوان مثال، یک امضاکننده ممکن است توکنی امضا شده توسط ارائهدهنده Google OpenID دریافت کند که نشان میدهد او به عنوان bob@gmail.com تأیید شده است و از کلید عمومی 0x54A5...FF استفاده میکند. سپس، هنگام دریافت پیامی که با همان کلید امضا شده است، گیرنده میتواند از توکن امضا شده توسط ارائهدهنده برای تأیید اینکه کلید bob@gmail.com 0x54A5...FF است و پیام واقعاً توسط bob@gmail.com امضا شده است، استفاده کند.
سادهسازی معماری از طریق برخی بدهبستانها (مانند وابستگی به ارائهدهندگان OpenID خارجی و فقدان یک گزارش تغییرات با هشینگ سلسله مراتبی) حاصل میشود که در برخی شرایط قابل قبول و در برخی دیگر نه. برای کاهش وابستگی به ارائهدهندگان OpenID، که نفوذ یا اقدامات پرسنل آنها میتواند سیستم را بیاعتبار کند (برای مثال، اگر یک هکر یک ارائهدهنده را به خطر بیندازد، میتواند یک کلید جعلی برای شخص ثالث صادر کند)، پیشنهاد میشود از یک MFA-Cosigner اضافی، اما اختیاری (Multi-Factor Authentication Cosigner) برای احراز هویت چند عاملی استفاده شود (توکن نه تنها باید توسط ارائهدهنده اصلی، بلکه توسط یک سرویس احراز هویت مستقل که کاربر را تأیید میکند نیز امضا شود).
یکی دیگر از نقاط ضعف OpenPubKey، وجود دادههای شخص ثالث است که میتواند برای ردیابی فعالیت در دورههای زمانی طولانی، صرف نظر از تغییر نام (استفاده مجدد از یک توکن شناسایی به جای یک گواهی جدید) مورد استفاده قرار گیرد. اتصال مستقیم به کلیدهای OpenID Connect در طول تأیید، نیاز به پیادهسازی سمت سرور را از بین میبرد، اما پیادهسازی سمت کلاینت را به طور قابل توجهی پیچیده میکند و فضای بیشتری برای مانور در هنگام حمله به کلاینت باقی میگذارد، به عنوان مثال، زیرا کلاینت مسئول چرخش کلید است. فقدان یک گزارش تغییرات، مانع از تشخیص نشتهای احتمالی کلید توسط کلاینت میشود.
منبع: opennet.ru
