Supply-chain Security با Signed Targets و Rollback Defense

این درس درباره‌ی ساخت یا حمله به یک سامانه‌ی به‌روزرسانی واقعی نیست. محیط SEC014-LAB1 کاملاً local و synthetic است: metadataها ساختگی‌اند، targetها فایل متنی بی‌خطر هستند و هیچ private key، package manager، repository بیرونی یا عملیات شبکه‌ای استفاده نمی‌شود. هدف این است که بتوانیم فرق میان «فایل با hash درست»، «metadata با authority درست»، «نمای سازگار repository» و «وضعیت تازه و غیر rollback» را با evidence جداگانه نشان دهیم.

خروجی اصلی درس Signed Update Trust & Freshness Record v1 است. هر ردیف آن باید Metadata Role / Trusted Key ID / Version / Expiry / Authorized Targets / Target Hash / Observed State / Acceptance Decision / Negative Evidence / Residual Risk را نگه دارد.

1. چرا signature یا hash به‌تنهایی کافی نیست

اگر hash یک target با metadata برابر باشد، فقط می‌فهمیم bytes مشاهده‌شده با digest مورد انتظار منطبق است. این گزاره به‌تنهایی نمی‌گوید چه کسی اجازه‌ی انتشار آن target را داشته، metadata هنوز تازه است، یا client قبلاً نسخه‌ی جدیدتری دیده است. به همین دلیل در مدل این درس digest آخرین gate است، نه کل trust model.

همین تفکیک درباره‌ی signature هم برقرار است. یک signature مصنوعی با وضعیت valid فقط وقتی معنا دارد که signer برای همان role و همان namespace مجاز باشد. اگر delegated role فقط plugins/ را پوشش دهد، همان signer نباید برای core/ authority فرض شود.

2. چهار نقش اصلی چه چیزی را ثابت می‌کنند

در مدل TUF، roleها مسئولیت‌های متفاوت دارند. root کلیدهای مورد اعتماد و authority roleهای بالادستی را معرفی می‌کند. targets اطلاعات targetهای مجاز را نگه می‌دارد و می‌تواند authority محدود را delegate کند. snapshot نسخه‌ی مجموعه‌ی metadataهای target را به یک view سازگار وصل می‌کند. timestamp با عمر کوتاه‌تر کمک می‌کند client متوجه شود snapshot ارائه‌شده بیش از حد قدیمی یا منقضی شده است.

هیچ‌کدام از این roleها به‌تنهایی «امن بودن معنایی نرم‌افزار» را اثبات نمی‌کنند. این درس فقط trust/freshness decision در fixture را ارزیابی می‌کند.

3. Root of trust و role separation

root نقطه‌ی شروع اعتماد است. در آزمایشگاه، کلیدها cryptographic نیستند و فقط شناسه‌های opaque مانند key:root-A هستند. client model از همین شناسه‌ها برای بررسی می‌کند که signer یک metadata role در مجموعه‌ی authority همان role قرار دارد یا نه.

Role separation برای محدودکردن blast radius است. اگر همه‌ی authority را به یک online identity بدهیم، مرز میان freshness، repository consistency و target authorization از بین می‌رود. مدل این درس چنین shortcutی را قبول نمی‌کند.

4. Targets و delegation

targets می‌تواند targetهای مستقیم یا delegationهای محدود را تعریف کند. مثال baseline دو namespace دارد: core/ برای به‌روزرسانی اصلی و plugins/ برای plugin channel. delegated role plugins-team فقط اجازه‌ی اعلام targetهایی با prefix plugins/ را دارد.

اگر target از plugins/widget-2.1.txt به core/widget-2.1.txt منتقل شود ولی signer و delegated role همان بمانند، باید DENY_DELEGATION_SCOPE ثبت شود. valid بودن وضعیت signature در fixture این boundary را دور نمی‌زند.

5. Snapshot و consistent view

Snapshot metadata نسخه‌ی metadataهای targets/delegations را به یک view متصل می‌کند. این مانع می‌شود client بدون evidence کافی metadataهایی از زمان‌های متفاوت را به‌عنوان یک state سازگار فرض کند. در fixture، snapshot فعلی version=12 است و client قبلاً حداقل همین نسخه را پذیرفته است.

اگر همان repository یک snapshot با version=11 ارائه دهد، مدل باید آن را rollback تشخیص دهد. حتی اگر target hash درست باشد، decision نهایی DENY_ROLLBACK_SNAPSHOT است؛ چون bytes درست نمی‌توانند freshness state را جایگزین کنند.

6. Timestamp و freeze boundary

Timestamp metadata در مدل یک version و expires دارد و به snapshot فعلی اشاره می‌کند. اگر timestamp منقضی باشد، client حق ندارد از آن یک freshness claim مثبت بسازد. در baseline تاریخ synthetic در محدوده‌ی معتبر است؛ در probe منفی expires عمداً به تاریخ گذشته تغییر می‌کند و نتیجه باید DENY_TIMESTAMP_EXPIRED شود.

این rejection به معنی اثبات وجود attack واقعی نیست. observed state فقط می‌گوید fixture نتوانست شرط freshness را برآورده کند.

7. Rollback با freeze یکی نیست

Rollback یعنی metadata قدیمی‌تر از state پذیرفته‌شده‌ی client ارائه شود. Freeze یعنی client برای مدت طولانی روی state قدیمی نگه داشته شود یا نتواند freshness را تأیید کند. هر دو به state و زمان وابسته‌اند؛ hash target به‌تنهایی هیچ‌کدام را حل نمی‌کند.

Evidence record باید دقیقاً نام failure boundary را حفظ کند: ROLLBACK_SNAPSHOT با TIMESTAMP_FRESHNESS یکی نیست.

8. Baseline: core channel

در baseline، root, targets, snapshot و timestamp همگی signer مجاز دارند. snapshot نسخه‌ی 12 و timestamp نسخه‌ی 40 دارد. target core/app-2.4.0.txt زیر authority مستقیم targets است و digest آن با fixture برابر است.

اجرای run_local_lab.py باید یک decision ACCEPT_TARGET تولید کند و در trace نشان دهد authority، rollback state، freshness و digest چهار gate جدا هستند. این output فقط evidence محلی است و production proof نیست.

9. Baseline: delegated plugin channel

برای plugins/widget-2.1.txt authority از targets به plugins-team delegate شده است. signer باید کلید مجاز همان delegated role باشد و path باید در namespace اعلام‌شده قرار بگیرد. سپس snapshot/timestamp و digest بررسی می‌شوند.

این مثال نشان می‌دهد «کلید trusted» بدون سؤال «برای کدام role و target scope؟» ناقص است.

10. Negative Evidence: rollback snapshot

در probe اول فقط snapshot version را از 12 به 11 کاهش می‌دهیم، درحالی‌که client state می‌گوید نسخه‌ی 12 قبلاً پذیرفته شده است. target bytes و digest هیچ تغییری نمی‌کنند. انتظار این است که decision در gate rollback متوقف شود.

این probe مهم است چون نشان می‌دهد integrity یک artifact و freshness repository دو claim مستقل هستند.

11. Negative Evidence: expired timestamp

در probe دوم timestamp منقضی می‌شود. مدل باید بدون تکیه بر target hash، freshness claim را رد کند. Evidence record باید expiry مشاهده‌شده را نگه دارد و inference را محدود کند: «freshness قابل اثبات نیست»، نه «حتماً مهاجم وجود دارد».

12. Negative Evidence: out-of-scope delegation

در probe سوم target delegated از plugins/* خارج می‌شود. signer همچنان همان key:plugins-A است و signature state در fixture همچنان valid است، اما authority path غلط است. نتیجه باید DENY_DELEGATION_SCOPE باشد.

این case از misconception «signature معتبر = authority نامحدود» جلوگیری می‌کند.

13. Evidence completeness

اگر یک ردیف evidence فیلدی مثل Version, Expiry, Authorized Targets یا Negative Evidence را حذف کند، دیگر نمی‌تواند bounded decision را پشتیبانی کند. validator داخلی دقیقاً schema record را بررسی می‌کند و extra/missing field را رد می‌کند.

Observed State باید output fixture را نگه دارد. Residual Risk باید inference محدود باشد و روشن کند که این lab هیچ real signing operation، package installation، key compromise analysis یا semantic malware safety را اثبات نمی‌کند.

14. Changed-context transfer

در transfer، دو channel مستقل داریم: plugins/ و core/. یادگیرنده نباید delegation namespace یا trusted role یکی را برای دیگری کپی کند. باید role، authorized target namespace، version/freshness state و target evidence هر channel را دوباره بسازد.

Template انتقال final_decision را خالی می‌گذارد. این blankness بخشی از human-accountability contract است؛ ابزار می‌تواند observation بدهد ولی تصمیم نهایی را به‌جای learner پر نمی‌کند.

15. مرز freshness منابع

بازبینی 20 سپتامبر 2026 فقط داخل سه source ID قفل‌شده انجام شده است. سطح‌های رسمی پروژه TUF دیگر یک برچسب patch-level یکتای Latest نشان نمی‌دهند؛ بنابراین این درس هیچ patch دقیقی را به‌عنوان آخرین نسخه TUF ادعا نمی‌کند و TUF-SPEC فقط خانواده جاری 1.x مورد استفاده این درس را مقید می‌کند. صفحه‌ی Roles and metadata همچنان Snapshot را برای consistent view و Timestamp را با عمر کوتاه‌تر برای freshness توضیح می‌دهد و صفحه‌ی Security نیز rollback و indefinite freeze را در threat model مستند می‌کند. این منابع فقط claimهای محدود همین درس را پشتیبانی می‌کنند و requirement محصول واقعی شما را تعیین نمی‌کنند.

16. خروجی نهایی درس

برای تکمیل SEC-014، Signed Update Trust & Freshness Record v1 باید حداقل یک positive case، rollback negative، expired timestamp negative، delegation-scope negative و changed-context transfer مستقل داشته باشد. owner_acceptance در starter خالی می‌ماند. این درس هیچ دستورالعملی برای حمله، bypass یا دست‌کاری سامانه‌ی به‌روزرسانی واقعی ارائه نمی‌کند.