محیط اجرای قابل اطمینان
جزئیات

استاندارد محیط اجرای قابل اطمینان با ساختن یک محیط جدا و ایزوله شده که به صورت موازی با سیستم عامل اجرا می‌شود، امنیت محیط غنی را فراهم می‌کند و برای داشتن امنیت بیشتر از سیستم عامل کاربرپسند به کار می‌رود. یکی از روش‌های پیاده‌سازی محیط اجرای قابل اطمینان استفاده از TrustZone یا منطقه امن پردازنده‌های ARM است. محیط اجرای قابل اطمینان TrustZone، برای محافظت از داده‌ها از یک روش ترکیبی که هم از سخت‌افزار و هم از نرم‌افزار بهره می‌برد، استفاده می‌کند. در نتیجه امنیت کافی را برای بسیاری از برنامه‌ها و کاربردها فراهم می‌کند. فقط برنامه‌های قابل اطمینان که در حال اجرا بر روی محیط اجرای قابل اطمینان TEE هستند به قدرت کامل پردازنده اصلی، لوازم جانبی و حافظه دسترسی دارند، در حالی که ایزوله بودن سخت‌افزار از این برنامه‌ها در برابر برنامه‌هایی که کاربر نصب کرده و در سیستم عامل اصلی اجرا می‌شوند، محافظت می‌کند. نرم‌افزار و جداسازهای داخل محیط اجرای قابل اطمینان از برنامه‌های درون این محیط در مقابل یکدیگر محافظت می‌کنند.
ارائه دهندگان خدمات، اپراتورهای شبکه تلفن همراه، توسعه دهندگان سیستم عامل، توسعه دهندگان برنامه‌ها، تولیدکنندگان دیوایس‌ها، عرضه‌کننده‌های پلتفرم و فروشندگان سیلیکون ذینفعان اصلی استانداردسازی محیط اجرای قابل اطمینان هستند و در این زمینه مشارکت دارند.
برای جلوگیری از شبیه‌سازی سخت‌افزار با نرم‌افزاری که توسط کاربر کنترل می‌شود، از «ریشه اعتماد سخت‌افزار» استفاده می‌شود. ریشه اعتماد سخت‌افزار مجموعه ای از کلیدهای خصوصی (که به آن‌ها «کلیدهای تأیید» یا «اسرار تأمین شده» گفته می‌شود) است که در هنگام تولید تراشه مستقیماً در آن تعبیه می‌شوند (معمولاً برای پیاده‌سازی این قسمت از حافظه‌هایی که فقط یک بار قابل برنامه‌ریزی هستند و مساحت زیادی هم دارند، مانند eFuse، استفاده می‌شود) کلیدهای روی ریشه اعتماد سخت افزار، قابل تغییر نیستند و کلیدهای عمومی مربوط به این کلیدهای خصوصی به همراه هش غیر مخفی کلید عمومی متعلق به طرف مورد اعتماد (معمولاً فروشنده تراشه) در پایگاه دادهٔ تولیدکننده قرار دارند و برای امضای نرم‌افزار قابل اعتماد دائمی ای که روی ROMحک شده و همچنین مدارهایی که عملیات رمزگذاری و کنترل سطح دسترسی را انجام می‌دهند استفاده می‌شود. این سخت‌افزار به نحوی طراحی شده‌است که از دسترسی تمام نرم‌افزارهایی که توسط کلید طرف مورد اعتماد امضا نشدند به قسمت محافظت شده، جلوگیری می‌کند. کلید عمومی فروشنده در زمان اجرا تولید و هش می‌شود. سپس این هش با نمونه تعبیه شده در تراشه مقایسه می‌شود. اگر هش منطبق باشد، از کلید عمومی برای تأیید امضای دیجیتالی firmware قابل اعتماد که توسط فروشنده کنترل می‌شود استفاده می‌شود (مثل زنجیرهٔ bootloaderها که در دستگاه‌های Android استفاده می‌شود). و بعد از آن firmware قابل اعتماد برای پیاده‌سازی تأیید از راه دور استفاده می‌شود.
یک مؤلفه غیر قابل اعتماد از یک برنامه برای تأیید اعتبار، مولفه قابل اطمینان را در حافظه قرار می‌دهد. سخت‌افزار از برنامه قابل اعتماد در برابر تغییر توسط مؤلفه‌های غیر قابل اعتماد محافظت می‌کند. سرور تصدیق کننده از طرف غیر قابل اطمینان درخواستی برای ارائه یک نانس می‌دهد. این نانس به عنوان بخشی از یک پروتکل احراز هویت و برای حفظ یکپارچگی برنامه قابل اعتماد است. اثبات به تأیید کننده ارسال می‌شود و توسط آن تأیید می‌شود. اثبات معتبر را نمی‌توان در سخت‌افزار شبیه‌سازی شده (یا QEMU) محاسبه کرد زیرا برای ساختن آن، نیاز است به کلیدهایی که بر روی سخت‌افزار تعبیه شده‌اند، دسترسی داشته باشیم. فقط firmwareهای قابل اعتماد به این کلیدها و / یا کلیدهای برگرفته از آنها یا با استفاده از آنها دسترسی دارند. از آنجا که پلتفرم طوری طراحی شده که فقط مالک آن به داده‌های ثبت شده در کارخانه است دسترسی داشته باشد، طرف تأیید کننده باید با سرویس تنظیم شده توسط فروشنده ارتباط برقرار کند. اگر این طرح به‌طور نادرست پیاده‌سازی شود، فروشنده تراشه می‌تواند برنامه‌هایی که در هر تراشه اجرا می‌شوند را بفهمد و با ارسال پیام عدم تأیید هویت به هرکدام که خواست اجازه دسترسی ندهد.
برای شبیه‌سازی سخت‌افزاری که بتواند تأیید هویت را از راه دور را انجام دهد، مهاجم باید کلیدها را از سخت‌افزار خارج کند، که به خاطر ابزار و مهارت‌های مورد نیاز برای مهندسی معکوس (focused ion beam, scanning electron microscope, microprobing, decapsulation) بسیار پرهزینه یا اگر این سخت‌افزار طوری طراحی شده باشد که مهندسی معکوس کلیدها را از بین ببرد به‌طور کلی غیرممکن است. در بعضی موارد، کلیدها برای هر قطعه سخت‌افزاری متمایزند، درنتیجه کلیدی که از یک تراشه استخراج می‌شود، برای بقیه بی فایده است.
اگرچه محرومیت از مالکیت یک ویژگی ذاتی محیط اجرای قابل اطمینان نیست (این امکان وجود دارد که طراحی سیستم به طوری انجام شود که فقط کاربرانی که اول مالکیت دستگاه را بدست آورده‌اند بتوانند سیستم آن را کنترل کنند)، اما در عمل همه این سیستم‌های مصرفی عمداً طوری طراحی شده‌اند که به تولیدکنندگان تراشه اجازه می‌دهند که دسترسی به تصدیق و الگوریتم‌های آن را کنترل کنند. در نتیجه سازنده‌ها می‌توانند اجازه دسترسی به محیط اجرای قابل اطمینان را فقط به توسعه دهندگان نرم‌افزاری که با سازنده توافق تجاری دارند، اعطا کنند، و موارد استفاده مانند Tivoization و DRM را فعال کنند.