مقدمه: مسئلهٔ اعتماد در به‌روزرسانی
واقعیت منبع: «The Update Framework Specification» نسخهٔ ۱.۰.۳۷، با آخرین ویرایش ۸ اکتبر ۲۰۲۶، TUF را چارچوبی برای امن‌سازی سامانه‌های به‌روزرسانی معرفی می‌کند. مرور کلی رسمی می‌گوید به‌روزرسانی‌ها قابلیت تازه و اصلاح آسیب‌پذیری می‌آورند، اما جریان دائمی دریافت فایل و فراداده، فرصت حمله نیز ایجاد می‌کند. TUF مجموعه‌ای از کتابخانه‌ها، قالب‌های فایل و ابزارهاست، نه قالب بسته یا نصب‌کنندهٔ عمومی.
تحلیل تحریریه: تکیه بر یک کلید، URL یا سرور مرکزی کافی نیست. TUF اعتماد را میان نقش‌ها، کلیدهای متعدد، آستانهٔ امضا، شمارهٔ نسخه، زمان انقضا و هش تقسیم می‌کند. بنابراین افشای یک کلید یا خراب‌شدن یک آینه (Mirror) نباید خودبه‌خود به نصب فایل دلخواه برسد. این چارچوب لایهٔ اعتماد و تحویل است؛ جایگزین سیاست نصب، مدیریت دستگاه و پاسخ‌گویی سازمانی نیست.
دامنهٔ حفاظت و مرزهای TUF
فایل‌های توزیع‌شده «فایل هدف» (Target file) هستند و برای چارچوب شفاف نیستند: می‌توانند بسته، باینری، متن یا مجموعه‌ای از فایل‌ها باشند. فراداده مسیر، طول و هش هدف و نقش مجاز را ثبت می‌کند. کلاینت ابتدا مخزن را بررسی می‌کند و فقط هدفی را در اختیار برنامه می‌گذارد که فرادادهٔ به‌موقع و درست‌امضا آن را معرفی کرده باشد.
TUF نصب، اجرای مهاجرت، قالب بسته یا بوت‌استرپ امنِ نصب نرم‌افزار دلخواه را انجام نمی‌دهد. کاربر همچنان به روشی دیگر باید اصالت نصب اولیه را بسنجد. همچنین چارچوب در همهٔ خطاها تصمیم نهایی را نمی‌گیرد؛ برنامه باید دربارهٔ توقف، تلاش دوباره یا واکنش عملیاتی تصمیم بگیرد. هدف آن افشای نرم‌افزار در حال به‌روزرسانی یا محتوای هدف نیست، اما این موضوع به‌تنهایی محرمانگی درخواست‌ها را تضمین نمی‌کند.
معماری نقش‌ها
همهٔ نقش‌ها می‌توانند چند کلید و یک آستانه (Threshold) داشته باشند. هر کلید فقط یک امضای مؤثر به آستانه اضافه می‌کند.
| نقش | کارکرد | نکتهٔ امنیتی |
|---|---|---|
| Root (ریشه) | کلیدهای مجاز نقش‌های سطح‌بالا، ازجمله خود Root، را معرفی می‌کند | کلید خصوصی باید بسیار امن و ترجیحاً آفلاین باشد |
| Targets (اهداف) | فرادادهٔ فایل‌های هدف را امضا می‌کند | خود فایل را امضا نمی‌کند؛ مشخصات فایل را معرفی می‌کند |
| Snapshot (نمایهٔ لحظه‌ای) | نسخهٔ تازهٔ Targets سطح‌بالا و همهٔ Targets واگذارشده را فهرست می‌کند | از حملهٔ درهم‌آمیزی (Mix-and-match) جلوگیری می‌کند |
| Timestamp (مهر زمانی) | بیانیهٔ دوره‌ای شامل هش Snapshot و انقضا را امضا می‌کند | آنلاین است، اما اعتماد محدودتری دارد |
| Mirrors (آینه‌ها) | فهرست اختیاری میزبان‌های دریافت است | می‌تواند سخت‌کد یا با فراداده امضا شود |
Root باید برای هر مخزن با کلیدهای مورد اعتماد در سمت کلاینت توزیع شود؛ این اعتماد اولیه خارج از باند (Out-of-band) شکل می‌گیرد. فهرست Mirror سخت‌کدشده یا امضاشده، مسیر دریافت را تعیین می‌کند، اما معیار اصالت همچنان زنجیرهٔ فراداده است.
آستانه و کاهش اثر افشای کلید
آستانهٔ چندکلیدی مهاجم را مجبور می‌کند چند کلید مستقل را به‌دست آورد. آستانهٔ یک‌ازچند برای کاربردهای ساده ممکن است، اما مشخصات آن را ناامن می‌داند. کلید آنلاین در معرض خطر بیشتری است؛ به همین دلیل کلید آنلاین نباید برای نقشی باشد که کلاینت در نهایت بر اساس آن فایل نصب‌شدنی را معتبر می‌داند. Timestamp استثنای کم‌اعتمادتر و طراحی‌شده برای عملیات خودکار است.
از نظر عملی، کلیدهای Root، Targets و Snapshot را بر اساس نقش جدا کنید و، جز Timestamp و Mirrors، در فضای آفلاین رمزگذاری‌شده، ماشین مستقل یا سخت‌افزار ویژه نگه دارید. آستانه را با تعداد اپراتورهای مستقل و توان بازیابی هماهنگ کنید: آستانهٔ بزرگ بدون فرایند امضای در دسترس، سرویس را می‌خواباند و آستانهٔ کوچکِ متمرکز، مزیت تفکیک را کم می‌کند.
Delegation؛ واگذاری محدود و قابل لغو
Targets می‌تواند اعتماد کامل یا جزئی را به نقش دیگری بسپارد. واگذاری جزئی، نقش فرزند را فقط برای بعضی مسیرها یا هدف‌ها معتبر می‌کند. نقش فرزند نیز می‌تواند واگذار کند؛ بااین‌حال والد همچنان مسئول زنجیره است. لغو، با انتشار فرادادهٔ جدیدی انجام می‌شود که واگذاری را حذف کرده باشد.
این مدل برای مخزن بزرگ مفید است: تیم‌ها حوزهٔ خود را امضا می‌کنند و کلید مرکزی Targets برای هر فایل لازم نیست. دامنهٔ هر delegation را کوچک، مسیر آن را مستند و تغییرش را ممیزی کنید. کلاینت از Targets سطح‌بالا به‌شکل پیمایش عمقیِ پیش‌مرتب جلو می‌رود؛ چرخه‌ها را کنار می‌گذارد و سقف تعداد نقش‌ها را رعایت می‌کند تا مهاجم نتواند زمان یا پهنای‌باند را هدر دهد. واگذاری خاتمه‌دهنده جست‌وجو را متوقف می‌کند و واگذاری غیرخاتمه‌دهنده اجازهٔ بررسی مسیر بعدی را می‌دهد.
threat model و حمله‌های اصلی
مدل تهدید، مهاجمی را فرض می‌کند که به درخواست کلاینت پاسخ می‌دهد، مرد میانی (Man-in-the-middle) است یا Mirror را در اختیار گرفته است. او در بدترین حالت می‌تواند به‌روزرسانی را متوقف کند؛ اما نباید بتواند هدف دلخواه معتبر جا بزند. کنترل‌های مهم چنین‌اند:
- Rollback (بازگشت): نسخهٔ قدیمی‌تر از آنچه کلاینت قبلاً می‌شناخته پذیرفته نمی‌شود.
- Freeze (یخ‌زدگی): انقضا باید از زمان ثابت شروع چرخه جلوتر باشد؛ وگرنه بازپخش فرادادهٔ قدیمی گزارش می‌شود.
- Mix-and-match: Snapshot نسخهٔ Targets سطح‌بالا و نقش‌های واگذارشده را تثبیت می‌کند و Timestamp هش Snapshot را می‌سنجد.
- Fast-forward: مهاجم نمی‌تواند بی‌قاعده شمارهٔ نسخه را بالا ببرد؛ بعد از چرخش کلید Timestamp یا Snapshot، کلاینت فرادادهٔ مورد اعتماد آن‌ها را پاک می‌کند تا بازیابی ممکن شود.
- نصب دلخواه، وابستگی اضافی و دادهٔ بی‌نهایت: هدف باید در فراداده معرفی شود، وابستگی خارج از انتظار نباید تحمیل شود و دانلود باید سقف بایت داشته باشد.
- Mirror مخرب: Mirror بد می‌تواند قطع سرویس ایجاد کند، اما نباید Mirror خوب را از ارائهٔ به‌روزرسانی بازدارد.
این کنترل‌ها موفقیت دریافت را تضمین نمی‌کنند. مهاجمِ قادر به قطع ارتباط همیشه می‌تواند حملهٔ منع خدمت (DoS) انجام دهد؛ دستاورد TUF، تشخیص ناتوانی و تحویل‌ندادن فایل مشکوک است.
Consistent snapshots و CDN
در مخزن پرتغییر، خواندن هم‌زمان با نوشتن می‌تواند کلاینت را به فرادادهٔ ناهماهنگ برساند. در consistent snapshot هر انتشار خودبسنده است: متادیتا با VERSION_NUMBER.FILENAME.EXT و هدف با HASH.FILENAME.EXT ذخیره می‌شود. Timestamp چون بدون دانستن نسخه درخواست می‌شود، بدون پیشوند می‌ماند. ارجاع داخلی فراداده همچنان نام منطقی فایل را دارد، نه نام پیشونددار؛ در غیر این صورت کلیدهای آفلاین باید با هر نام فیزیکی دوباره امضا کنند. Root هنگام استفاده باید ویژگی بولی consistent_snapshot را فعال اعلام کند.
برای CDN یا ذخیره‌ساز شیء، این یعنی مسیر تحویل را می‌توان تا حدی بی‌اعتماد فرض کرد. CDN فایل را می‌رساند، اما Timestamp، Snapshot و Targets باید امضای درست، نسخه، انقضا، طول و هش درست داشته باشند. HTTPS مفید است، ولی جایگزین امضای نقش‌ها نیست و TUF برای کار در محیط فاقد TLS نیز طراحی شده است.
گردش کار اعتبارسنجی کلاینت
۱. کلاینت زمان ثابت شروع را ثبت می‌کند تا انقضا در میانهٔ همان چرخه رفتار متناقض نداشته باشد.
۲. Root مورد اعتمادِ همراه Updater بارگذاری می‌شود. انقضای نسخهٔ قبلی مانع تلاش برای به‌روزرسانی Root نیست.
۳. Rootهای بعدی یکی‌یکی دریافت می‌شوند. نسخهٔ N+1 باید هم با آستانهٔ Root نسخهٔ N و هم با آستانهٔ تعریف‌شده در Root تازه امضا شود و دقیقاً یک واحد جلو برود؛ سپس روی ذخیره‌ساز پایدار نوشته شود.
۴. Timestamp دریافت و از نظر امضا، افزایش نسخه، رابطهٔ نسخهٔ Snapshot و انقضا بررسی می‌شود. نسخهٔ برابر تغییر تازه‌ای ندارد و نسخهٔ پایین‌تر بازگشت است.
۵. Snapshot با هش ثبت‌شده در Timestamp، آستانهٔ Snapshot و شمارهٔ نسخه تطبیق داده می‌شود. نسخهٔ Targets و نقش‌های واگذارشده نباید از نسخهٔ قبلی پایین‌تر باشد.
۶. Targets با هش و نسخهٔ ثبت‌شده در Snapshot و امضای نقش بررسی می‌شود. بعد، مسیر delegation برای هدف خواسته‌شده پیموده می‌شود.
۷. طول دانلود هدف محدود و هش آن با فراداده مقایسه می‌شود. تنها پس از موفقیت همهٔ این کنترل‌ها، فایل در اختیار برنامه قرار می‌گیرد.
چرخش Root و واکنش به افشا
برای جایگزینی کلید Root یا هر نقش سطح‌بالا، Root فایل root.json تازه‌ای با کلیدهای جدید می‌سازد. در چرخش Root، فایل جدید باید با آستانه‌ای از کلیدهای قدیمی و آستانه‌ای از کلیدهای جدید امضا شود. کلاینت عقب‌مانده فایل‌های میانی را به ترتیب می‌گیرد تا زنجیرهٔ اعتماد قطع نشود. اگر کمتر از آستانهٔ Root افشا شود، چرخش عادی می‌تواند اعتماد به آن کلید را لغو کند. اگر آستانه افشا شده باشد، به‌روزرسانی Root باید خارج از باند انجام شود و سازمان باید احتمال نصب بدافزار و تصرف دستگاه را جدی بگیرد. این رویداد فقط تعویض فایل کلید نیست؛ بررسی دستگاه، توقف انتشار، بازبینی لاگ و بازسازی اعتماد لازم است. کلید توسعه‌دهندهٔ واگذارشده با فرادادهٔ امضاشدهٔ نقش والد عوض می‌شود.
مزایا، محدودیت‌ها و حریم خصوصی
مزیت اصلی، تفکیک اختیار و بررسی مستقل از مسیر شبکه است: طول و هش دست‌کاری فایل را آشکار می‌کند؛ نسخه و زمان با بازپخش مقابله می‌کنند؛ Snapshot هم‌زمانی را نگه می‌دارد؛ delegation دامنهٔ اختیار را کم می‌کند و آستانه اثر افشای یک کلید را محدود می‌سازد. در مقابل، افشای تعداد کافی کلید، خطای انقضا یا چرخش و قطع Mirror همچنان خطرآفرین است. نگهداری آفلاین و امضای چندنفره هزینه دارد و TUF محتوای هدف را از نظر بدافزار یا کیفیت تحلیل نمی‌کند.
هدف چارچوب، افشای نرم‌افزار یا محتوای به‌روزرسانی نیست؛ اما TUF ناشناس‌سازی درخواست، پنهان‌کردن نشانی شبکه، حذف لاگ CDN یا رمزگذاری محتوا را تضمین نمی‌کند. برای حریم خصوصی باید حداقل‌سازی لاگ، نگهداری محدود و کنترل دسترسی جداگانه اعمال شود. در چندمخزنی، هر مخزن Root و کلیدهای مستقل دارد و TUF محتوای مورد اعتماد را مخلوط نمی‌کند؛ تصمیم دربارهٔ تعارض بر عهدهٔ برنامه است.
راهنمای دفاعی برای بهره‌برداری مشروع
۱. مخزن‌ها، کلاینت‌ها و دامنهٔ هر Target را فهرست کنید؛ Root اولیه را خارج از باند با چند مسئول تطبیق دهید.
۲. برای Root، Targets و Snapshot کلید مستقل و آفلاین، و برای Timestamp سرویس آنلاین با دسترسی کم تعیین کنید. آستانه را در محیط آزمایشی بسنجید.
۳. delegation را کم‌دامنه کنید، مسیر و نقش‌های خاتمه‌دهنده را ثبت و سقف پیمایش را تنظیم کنید.
۴. برای هر هدف طول و هش ثبت کنید؛ نسخهٔ فراداده را افزایش دهید؛ Targets، Snapshot و Timestamp را به‌ترتیب امضا و منتشر کنید.
۵. در مخزن پرتغییر، consistent snapshot را فعال و نام نسخه‌دار متادیتا و نام هش‌دار هدف را با کلاینت قدیمی و جدید آزمایش کنید.
۶. در آزمون مجاز، Mirror قطع‌شده، پاسخ قدیمی، نسخهٔ جهش‌کرده، هش نادرست، امضای زیر آستانه و delegation چرخه‌ای را شبیه‌سازی کنید. نتیجهٔ درست، توقف امن و گزارش است، نه نصب.
۷. چرخش کلید، افشای کمتر از آستانه، افشای آستانه و بازسازی دستگاه را تمرین کنید؛ Rootهای میانی و لاگ امضا را نگه دارید.
چک‌لیست
- [ ] Root اولیه خارج از باند و روی ذخیره‌ساز پایدار اعتبارسنجی شده است.
- [ ] کلیدها و آستانهٔ هر نقش با سیاست سازمانی منطبق است.
- [ ] کلیدهای غیر Timestamp و غیر Mirrors آفلاین‌اند.
- [ ] نسخه، انقضا، طول و هش همهٔ فراداده‌ها و اهداف آزموده شده است.
- [ ] Timestamp به Snapshot درست و Snapshot به Targets لازم اشاره می‌کند.
- [ ] Rootهای میانی برای چرخش تدریجی در دسترس‌اند.
- [ ] رفتار CDN و Mirror خصمانه بدون امکان جعل امضا آزمایش شده است.
- [ ] خطای امضا، بازگشت، انقضا و قطع Mirror هرگز به نصب منتهی نمی‌شود.
- [ ] لغو delegation، چرخش کلید و بازیابی پس از افشا مستند است.
پرسش‌های متداول
آیا TUF به HTTPS وابسته است؟
خیر. استفاده از TLS اختیاری است؛ اصالت به امضا، نسخه، انقضا و هش متکی است. HTTPS به‌تنهایی جای زنجیرهٔ نقش‌ها را نمی‌گیرد.
اگر Mirror خراب باشد چه می‌شود؟
ممکن است دریافت متوقف شود، اما فایل نامعتبر نباید پذیرفته شود و در صورت وجود Mirror خوب، کلاینت می‌تواند از آن استفاده کند. DoS کامل همچنان ممکن است.
چرا Timestamp آنلاین است؟
چون مرتب تولید می‌شود و هش Snapshot را حمل می‌کند. اعتمادش محدودتر است و این موضوع مجوز آنلاین‌کردن Root نیست.
آیا امضای Targets باینری را امن می‌کند؟
فقط نشان می‌دهد فایل همان فایل معرفی‌شده است؛ تحلیل بدافزار، مجوز، سازگاری و نصب با منتشرکننده و برنامه است.
آیا TUF حریم خصوصی را حل می‌کند؟
خیر. هدفش حفاظت از زنجیرهٔ به‌روزرسانی است و برای شبکه، لاگ و محرمانگی باید کنترل‌های جداگانه داشت.
نتیجه‌گیری
TUF اعتماد را از یک URL و یک کلید به زنجیره‌ای قابل ممیزی تبدیل می‌کند: Root مرجع کلیدهاست، Targets اختیار معرفی فایل را دارد، Snapshot هم‌زمانی را حفظ می‌کند و Timestamp تازگی را می‌سنجد؛ delegation و consistent snapshot نیز مقیاس‌پذیری را ممکن می‌کنند. مصونیت مطلق وجود ندارد: مهاجم می‌تواند سرویس را قطع کند و افشای آستانهٔ کلید واکنش اضطراری می‌خواهد. اما Root آفلاین، آستانهٔ مستقل، چرخش مرحله‌ای، کنترل طول و هش و توقف امن، به سازمان اجازه می‌دهد میان «از شبکه دریافت شد» و «واقعاً قابل اعتماد است» تمایز بگذارد.
