احراز هویت با TPM – اعتماد از سطح سخت‌افزار با راهکارهای نشانه

حملات سایبری هر روز پیچیده‌تر می‌شوند و مهاجمان ابزارهای پیشرفته‌تری برای نفوذ به سیستم‌ها در اختیار دارند. سازمان‌ها نمی‌توانند تنها با نرم‌افزارهای امنیتی از داده‌های حساس خود محافظت کنند. چرا که هر نرم‌افزاری، صرف‌نظر از پیچیدگی‌اش، می‌تواند دارای آسیب‌پذیری باشد یا توسط بدافزارهای پیشرفته دور زده شود. اینجاست که مفهوم احراز هویت با TPM به عنوان یک لایه امنیتی سخت‌افزاری وارد عمل می‌شود.

Trusted Platform Module یا ماژول پلتفرم مورد اعتماد، یک تراشه رمزنگاری مستقل است که مستقیماً روی برد اصلی سیستم نصب می‌شود و به عنوان ریشه اعتماد سخت‌افزاری عمل می‌کند. این تراشه کوچک قادر است عملیات رمزنگاری پیچیده را انجام دهد، کلیدهای خصوصی را در محیطی ایمن ذخیره کند و صحت سخت‌افزار و نرم‌افزار سیستم را تأیید نماید. از طریق TPM، احراز هویت دیگر فقط بر اساس اطلاعاتی که کاربر می‌داند (مانند رمز عبور) انجام نمی‌شود، بلکه بر اساس چیزی که کاربر دارد (تراشه فیزیکی TPM) و وضعیت امنیتی دستگاه او صورت می‌گیرد.

در این مقاله جامع، به بررسی عمیق معماری TPM، یکپارچگی آن با استاندارد FIDO، کاربردهای عملی در احراز هویت چندعاملی، و نحوه پیاده‌سازی این فناوری با راهکارهای نشانه خواهیم پرداخت. هدف ما ارائه راهنمایی است که سازمان‌ها بتوانند با اطمینان، امنیت سخت‌افزاری را در زیرساخت احراز هویت خود به کار گیرند.

TPM چیست؟ معرفی ماژول پلتفرم مورد اعتماد

Trusted Platform Module تراشه‌ای امنیتی است که وظیفه اصلی آن ایجاد و نگهداری یک Hardware Root of Trust برای سیستم است. TPM می‌تواند به صورت یک تراشه جداگانه روی مادربرد (discrete TPM یا dTPM) یا به صورت پیاده‌سازی نرم‌افزاری در فریم‌ور (firmware TPM یا fTPM) وجود داشته باشد. هر دو نوع توسط استانداردهای Trusted Computing Group (TCG) تعریف شده‌اند و وظایف یکسانی را انجام می‌دهند، هرچند dTPM از نظر امنیتی مقاوم‌تر است.

این تراشه مجموعه‌ای از قابلیت‌های رمزنگاری را ارائه می‌دهد که شامل تولید کلیدهای RSA و ECC، هش کردن با الگوریتم‌های SHA، رمزنگاری متقارن با AES و عملیات HMAC است. TPM دارای حافظه غیرفرار است که کلیدهای خصوصی را حتی پس از خاموش شدن سیستم حفظ می‌کند. این کلیدها هرگز از TPM خارج نمی‌شوند و تمام عملیات رمزنگاری درون خود تراشه انجام می‌پذیرد.

یکی از مهم‌ترین ویژگی‌های TPM، Platform Configuration Registers (PCRs) هستند. این رجیسترها مقادیر هش مربوط به وضعیت سیستم را ذخیره می‌کنند. در طول فرآیند بوت، هر مرحله (BIOS، بوت‌لودر، کرنل) قبل از اجرا، هش خود را در PCR ثبت می‌کند. این زنجیره اعتماد اطمینان می‌دهد که سیستم از یک حالت شناخته شده و امن بوت شده است. اگر بدافزاری بخواهد خود را در مسیر بوت قرار دهد، مقادیر PCR تغییر خواهند کرد و سیستم می‌تواند این تغییر را تشخیص دهد.

تاریخچه تکامل TPM از نسخه 1.2 تا 2.0

نسخه اولیه TPM 1.2 در سال 2003 منتشر شد و الگوریتم‌های رمزنگاری محدودی را پشتیبانی می‌کرد. این نسخه عمدتاً روی RSA تمرکز داشت و از الگوریتم‌های SHA-1 استفاده می‌کرد که امروزه امن نیستند. TPM 1.2 همچنین با یک سیستم‌عامل خاص (معمولاً ویندوز) سازگار بود و پیاده‌سازی آن در لینوکس یا سیستم‌های دیگر دشوار بود.

در سال 2014، TCG مشخصات TPM 2.0 را منتشر کرد که تحولی بزرگ در این فناوری بود. TPM 2.0 از الگوریتم‌های رمزنگاری مدرن مانند ECC (Elliptic Curve Cryptography) و SHA-256 پشتیبانی می‌کند. این نسخه انعطاف‌پذیری بیشتری دارد و می‌تواند با الگوریتم‌های مختلف پیکربندی شود. TPM 2.0 همچنین استقلال از سیستم‌عامل دارد و می‌تواند در ویندوز، لینوکس، اندروید و سایر پ رمزنگاری مدرن مانند ECC (Elliptic Curve Cryptography) و SHA-256 پشتیبانی می‌کند. این نسخه انعطاف‌پذیری بیشتری دارد و می‌تواند با الگوریتم‌های مختلف پیکربندی شود. TPM 2.0 همچنین استقلال از سیستم‌عامل دارد و می‌تواند در ویندوز، لینوکس، اندروید و سایر پلتفرم‌ها به کار رود.

یکی از نوآوری‌های مهم TPM 2.0، پشتیبانی از چند سلسله مراتب کلید است. در TPM 1.2، تنها یک کلید ریشه (SRK – Storage Root Key) وجود داشت، اما TPM 2.0 امکان ایجاد چندین سلسله مراتب کلیدی را فراهم می‌کند که هر کدام می‌توانند برای اهداف متفاوت (رمزنگاری، امضای دیجیتال، احراز هویت) استفاده شوند. این قابلیت باعث می‌شود TPM 2.0 برای کاربردهای سازمانی پیچیده مناسب‌تر باشد.

تفاوت‌های معماری dTPM و fTPM

Discrete TPM (dTPM) یک تراشه فیزیکی جداگانه است که مستقیماً روی مادربرد سیستم لحیم‌کاری شده یا در یک سوکت قابل تعویض نصب می‌شود. این نوع TPM دارای پردازنده رمزنگاری اختصاصی و حافظه مستقل است. dTPM از نظر امنیتی بالاترین سطح محافظت را ارائه می‌دهد زیرا به صورت فیزیکی از سایر اجزای سیستم جدا است و حملات نرم‌افزاری نمی‌توانند مستقیماً به آن دسترسی پیدا کنند.

Firmware TPM (fTPM) یک پیاده‌سازی نرم‌افزاری از مشخصات TPM است که در یک محیط اجرایی امن مانند Intel ME یا AMD PSP اجرا می‌شود. fTPM از همان APIها و قابلیت‌های TPM استفاده می‌کند اما به جای تراشه فیزیکی، از یک محیط ایزوله شده در فریم‌ور استفاده می‌کند. مزیت اصلی fTPM، هزینه پایین‌تر و انعطاف‌پذیری در به‌روزرسانی است. با این حال، fTPM در برابر حملات پیچیده آسیب‌پذیرتر است زیرا در همان پردازنده اصلی اجرا می‌شود.

در عمل، بسیاری از لپ‌تاپ‌های مدرن و دستگاه‌های سازمانی از dTPM استفاده می‌کنند زیرا سازمان‌ها نیاز به بالاترین سطح امنیت دارند. از سوی دیگر، دستگاه‌های مصرف‌کننده پایین‌تر ممکن است از fTPM استفاده کنند تا هزینه تولید کاهش یابد. هر دو نوع توسط ویندوز 11 به عنوان نیازمندی سیستم پذیرفته شده‌اند، اما سازمان‌هایی که حساسیت امنیتی بالایی دارند، ترجیح می‌دهند روی dTPM تکیه کنند.

معماری داخلی TPM – اجزای حیاتی تراشه امنیتی

برای درک کامل نحوه عملکرد احراز هویت با TPM، باید با معماری داخلی این تراشه آشنا شویم. TPM از چندین بخش کلیدی تشکیل شده که هر کدام نقش خاصی در ایجاد امنیت سخت‌افزاری دارند.

در مرکز معماری TPM، موتور رمزنگاری قرار دارد. این واحد عملیات‌های سنگین ریاضی مورد نیاز برای الگوریتم‌های رمزنگاری را انجام می‌دهد. موتور رمزنگاری TPM 2.0 از الگوریتم‌های مختلفی پشتیبانی می‌کند از جمله RSA با کلیدهای 2048 و 4096 بیتی، ECC با منحنی‌های NIST P-256 و P-384، AES با طول کلید 128 و 256 بیت، و توابع هش SHA-256 و SHA-384. این تنوع امکان می‌دهد TPM با استانداردهای رمزنگاری مختلف سازگار باشد.

حافظه غیرفرار (Non-Volatile Memory) بخشی است که کلیدهای خصوصی، گواهینامه‌ها و سایر داده‌های حساس را ذخیره می‌کند. این حافظه حتی زمانی که برق سیستم قطع است، محتوای خود را حفظ می‌کند. مهم‌تر اینکه دسترسی به این حافظه محافظت‌شده است و نرم‌افزارهای معمولی نمی‌توانند مستقیماً محتوای آن را بخوانند. هر عملیات رمزنگاری با کلید خصوصی درون خود TPM انجام می‌شود و کلید هرگز خارج از تراشه منتقل نمی‌گردد.

Platform Configuration Registers مجموعه‌ای از رجیسترهای 256 بیتی هستند که برای ذخیره مقادیر هش استفاده می‌شوند. TPM 2.0 معمولاً حداقل 24 PCR دارد که هر کدام می‌توانند برای اندازه‌گیری اجزای مختلف سیستم استفاده شوند. این رجیسترها تنها با عملیات Extend قابل تغییر هستند که مقدار جدید را با مقدار قبلی هش می‌کند و نتیجه را ذخیره می‌کند. این طراحی تضمین می‌کند که تاریخچه کامل تغییرات قابل ردیابی است و نمی‌توان مقادیر قبلی را دستکاری کرد.

موتور رمزنگاری و الگوریتم‌های پشتیبانی شده

موتور رمزنگاری TPM برای انجام عملیات‌های رمزنگاری با کارایی بالا طراحی شده است. این واحد می‌تواند عملیات رمزنگاری متقارن و نامتقارن را به طور هم‌زمان انجام دهد. برای رمزنگاری متقارن، TPM از AES در حالت‌های مختلف (CFB، ECB، CBC) استفاده می‌کند. این حالت‌ها برای رمزنگاری داده‌های ذخیره شده و ارتباطات امن به کار می‌روند.

برای عملیات کلید عمومی، TPM از RSA و ECC پشتیبانی می‌کند. RSA برای سازگاری با سیستم‌های قدیمی مهم است، اما ECC به دلیل کارایی بهتر و طول کلید کوتاه‌تر برای برابری امنیتی، در حال محبوب‌تر شدن است. یک کلید ECC 256 بیتی امنیتی معادل کلید RSA 3072 بیتی دارد، اما عملیات روی آن سریع‌تر است و فضای کمتری اشغال می‌کند.

TPM همچنین از HMAC برای تأیید یکپارچگی پیام پشتیبانی می‌کند. HMAC با استفاده از یک کلید مخفی و تابع هش، امضای دیجیتالی برای داده‌ها ایجاد می‌کند. این قابلیت در پروتکل‌های احراز هویت و تبادل امن داده کاربرد دارد. علاوه بر این، TPM شامل یک مولد عدد تصادفی سخت‌افزاری (HRNG) است که برای تولید کلیدهای رمزنگاری و nonce های امن استفاده می‌شود. کیفیت اعداد تصادفی تولید شده توسط HRNG بسیار بالاست و آنتروپی کافی برای کاربردهای حیاتی امنیتی را فراهم می‌کند.

حافظه غیرفرار و محافظت از کلیدهای خصوصی

یکی از مهم‌ترین جنبه‌های TPM، نحوه ذخیره و محافظت از کلیدهای خصوصی است. TPM دارای سلسله مراتب کلیدی است که در آن یک کلید ریشه اولیه (Primary Key) وجود دارد که هرگز از TPM خارج نمی‌شود. این کلید ریشه به طور خودکار در اولین استفاده از TPM تولید می‌شود یا توسط مالک TPM ایجاد می‌گردد.

کلیدهای دیگر به صورت سلسله‌مراتبی از کلید ریشه مشتق می‌شوند. به این ترتیب، TPM می‌تواند صدها کلید مختلف را مدیریت کند بدون اینکه همه آنها را در حافظه غیرفرار ذخیره کند. هنگامی که نیاز به استفاده از یک کلید باشد، TPM می‌تواند آن را بر اساس کلید والد و پارامترهای مشتق‌سازی بازسازی کند. این روش کلیدهای گذرا (Transient Keys) نامیده می‌شود و فضای حافظه را بهینه می‌کند.

کلیدهای حساس‌تر می‌توانند در حافظه غیرفرار ذخیره شوند. TPM دارای محدودیت فضایی است، معمولاً حدود 7KB تا 32KB حافظه غیرفرار در اختیار دارد. بنابراین، تنها کلیدهایی که واقعاً بحرانی هستند و نیاز به دسترسی سریع دارند، در این فضا ذخیره می‌شوند. بقیه کلیدها می‌توانند به صورت رمزشده در سیستم فایل عادی ذخیره شوند و فقط هنگام استفاده در TPM بارگذاری شوند.

محافظت از کلیدها همچنین شامل سیاست‌های دسترسی است. هر کلید در TPM می‌تواند دارای سیاست پیچیده‌ای باشد که شرایط استفاده از آن را تعیین می‌کند. به عنوان مثال، یک کلید می‌تواند تنها زمانی قابل استفاده باشد که PCRهای خاصی مقادیر مشخصی داشته باشند، یا نیاز به احراز هویت با رمز عبور یا بیومتریک باشد. این سیاست‌ها امکان پیاده‌سازی کنترل دسترسی دقیق را فراهم می‌کنند.

Platform Configuration Registers (PCR)

PCRها قلب مکانیزم Measured Boot هستند. در یک فرآیند بوت امن مبتنی بر TPM، هر مرحله از بوت قبل از انتقال کنترل به مرحله بعد، هش مرحله بعدی را محاسبه کرده و در PCR ثبت می‌کند. این فرآیند از BIOS/UEFI شروع می‌شود و تا بوت‌لودر، کرنل سیستم‌عامل و حتی درایورهای بارگذاری شده ادامه می‌یابد.

فرض کنید سیستم در حالت عادی بوت می‌شود. مقادیر PCR 0 تا 7 ممکن است به ترتیب شامل هش BIOS، پیکربندی پلتفرم، ROM کد اختیاری، بوت‌لودر و پارتیشن بوت باشند. اگر مهاجمی بدافزاری را در بوت‌لودر جای‌گذاری کند، هش بوت‌لودر تغییر خواهد کرد و در نتیجه مقدار PCR مربوطه متفاوت خواهد بود.

سیستم یا برنامه‌ها می‌توانند مقادیر PCR را بخوانند و با مقادیر مورد انتظار مقایسه کنند. اگر تطابق نداشته باشند، سیستم می‌تواند به کاربر هشدار دهد یا دسترسی به داده‌های حساس را مسدود کند. این مکانیزم در ویژگی‌های امنیتی مانند BitLocker استفاده می‌شود: کلید رمزنگاری دیسک تنها زمانی از TPM آزاد می‌شود که PCRها مقادیر صحیح داشته باشند.

PCRها همچنین در Remote Attestation استفاده می‌شوند. یک سرور می‌تواند از دستگاه بخواهد که مقادیر PCR خود را به همراه امضای دیجیتال تولید شده توسط TPM ارسال کند. سرور با بررسی این امضا می‌تواند اطمینان حاصل کند که دستگاه در یک وضعیت امن بوت شده و قابل اعتماد است. این مکانیزم در سیستم‌های Zero Trust و Network Access Control اهمیت زیادی دارد.

عملیات اصلی TPM در احراز هویت

TPM سه عملیات اصلی دارد که در احراز هویت و امنیت سیستم نقش حیاتی ایفا می‌کنند: تولید و مدیریت کلیدها، Remote Attestation و Sealed Storage. هر یک از این قابلیت‌ها ویژگی‌های منحصربه‌فردی برای ایجاد یک محیط اجرایی امن فراهم می‌کنند.

تولید کلید در TPM به گونه‌ای طراحی شده که کلید خصوصی هرگز خارج از تراشه منتقل نشود. زمانی که برنامه‌ای درخواست تولید یک جفت کلید عمومی/خصوصی می‌کند، TPM کلیدها را درون خود تولید می‌کند. کلید عمومی به برنامه بازگردانده می‌شود تا بتوان آن را در گواهینامه‌ها یا عملیات رمزنگاری استفاده کرد، اما کلید خصوصی در TPM باقی می‌ماند. هر عملیاتی که نیاز به کلید خصوصی دارد، باید به TPM ارجاع شود و TPM نتیجه عملیات را برمی‌گرداند.

این معماری تضمین می‌کند که حتی اگر سیستم‌عامل یا برنامه‌های روی آن به خطر بیفتند، مهاجم نمی‌تواند کلید خصوصی را سرقت کند. برای سرقت کلید، مهاجم باید دسترسی فیزیکی به TPM داشته باشد و حملات پیچیده سخت‌افزاری انجام دهد که بسیار دشوار و پرهزینه است. این ویژگی TPM را به ابزاری ایده‌آل برای ذخیره کلیدهای احراز هویت FIDO، گواهینامه‌های دیجیتال و کلیدهای رمزنگاری تبدیل می‌کند.

تولید و مدیریت کلیدهای رمزنگاری

مدیریت چرخه حیات کلیدها در TPM شامل چندین مرحله است. ابتدا، کلید با الگوریتم و پارامترهای مشخص ایجاد می‌شود. TPM به کلید یک شناسه یکتا اختصاص می‌دهد که برنامه‌ها از آن برای ارجاع به کلید استفاده می‌کنند. سپس، کلید می‌تواند در حافظه غیرفرار ذخیره شود یا به صورت رمزشده در فایل سیستم نگهداری گردد.

هنگام استفاده، کلید در TPM بارگذاری می‌شود. TPM دارای تعداد محدودی اسلات برای کلیدهای فعال است، معمولاً 3 تا 10 اسلات بسته به پیاده‌سازی. اگر تمام اسلات‌ها پر باشند، کلیدی که کمتر استفاده شده Swap Out می‌شود و کلید جدید جایگزین آن می‌گردد. این مکانیزم شبیه مدیریت حافظه در سیستم‌عامل‌هاست.

کلیدها در TPM می‌توانند محدود باشند یا نامحدود. کلیدهای محدود (Restricted Keys) تنها برای عملیات خاصی قابل استفاده هستند. به عنوان مثال، یک کلید محدود برای Attestation فقط می‌تواند برای امضای Quoteها (گزارش‌های PCR) استفاده شود و نمی‌توان از آن برای امضای داده‌های دلخواه استفاده کرد. این محدودیت از سوءاستفاده کلیدها جلوگیری می‌کند.

TPM همچنین از کلیدهای سلسله‌مراتبی پشتیبانی می‌کند. یک کلید والد می‌تواند کلیدهای فرزند تولید کند که از آن مشتق شده‌اند. این ساختار امکان مدیریت گروهی کلیدها را فراهم می‌کند. به عنوان مثال، اگر یک سازمان بخواهد کلیدهای احراز هویت تمام کارمندان یک بخش را مدیریت کند، می‌تواند یک کلید والد مشترک ایجاد کند و سپس برای هر کاربر یک کلید فرزند تولید نماید.

Remote Attestation – تأیید صحت دستگاه از راه دور

Remote Attestation فرآیندی است که به وسیله آن یک سیستم می‌تواند وضعیت امنیتی خود را به طرف دیگری اثبات کند. این مکانیزم در سناریوهایی مانند دسترسی به شبکه سازمانی، احراز هویت به سرویس‌های ابری یا تراکنش‌های حساس مالی استفاده می‌شود.

فرآیند Attestation با درخواست یک Quote از TPM آغاز می‌شود. Quote یک ساختار داده است که شامل مقادیر فعلی PCRها و امضای دیجیتال آن مقادیر با یک کلید خصوصی ذخیره شده در TPM است. این کلید که Attestation Identity Key (AIK) نامیده می‌شود، معمولاً توسط یک مرجع اعتماد (مانند سازنده دستگاه یا سازمان مالک) گواهی شده است.

سرور دریافت‌کننده Quote ابتدا امضای دیجیتال را بررسی می‌کند تا اطمینان حاصل کند که Quote واقعاً از یک TPM معتبر آمده است. سپس، مقادیر PCR را با سیاست‌های امنیتی سازمان مقایسه می‌کند. اگر مقادیر با حالت مورد انتظار مطابقت داشته باشند، سرور می‌داند که دستگاه در وضعیت امن بوت شده و می‌تواند به آن اعتماد کند.

یکی از کاربردهای عملی Remote Attestation در Microsoft Intune و Azure AD است. سازمان‌ها می‌توانند سیاست تعریف کنند که کاربران تنها از دستگاه‌هایی که TPM فعال دارند و از Secure Boot استفاده می‌کنند، بتوانند به منابع حساس دسترسی پیدا کنند. زمانی که کاربر تلاش می‌کند وارد سیستم شود، Azure AD از TPM دستگاه او یک Quote درخواست می‌کند و بر اساس نتیجه، دسترسی را اعطا یا رد می‌نماید.

Sealed Storage – ذخیره‌سازی ایمن داده‌ها

Sealing فرآیندی است که داده‌ها را به وضعیت خاصی از سیستم مرتبط می‌کند. زمانی که داده‌ای Seal می‌شود، TPM آن را رمزنگاری کرده و شرط می‌گذارد که تنها زمانی قابل رمزگشایی است که PCRهای مشخصی مقادیر خاصی داشته باشند.

به عنوان مثال، فرض کنید می‌خواهیم کلید رمزنگاری دیسک BitLocker را در TPM Seal کنیم. ما کلید را به PCR 0، 1، 2، 4 و 7 متصل می‌کنیم که معمولاً مربوط به BIOS، پیکربندی پلتفرم و بوت‌لودر هستند. TPM کلیدaling** فرآیندی است که داده‌ها را به وضعیت خاصی از سیستم مرتبط می‌کند. زمانی که داده‌ای Seal می‌شود، TPM آن را رمزنگاری کرده و شرط می‌گذارد که تنها زمانی قابل رمزگشایی است که PCRهای مشخصی مقادیر خاصی داشته باشند.

به عنوان مثال، فرض کنید می‌خواهیم کلید رمزنگاری دیسک BitLocker را در TPM Seal کنیم. ما کلید را به PCR 0، 1، 2، 4 و 7 متصل می‌کنیم که معمولاً مربوط به BIOS، پیکربندی پلتفرم و بوت‌لودر هستند. TPM کلید را رمزنگاری کرده و فقط زمانی آن را رمزگشایی می‌کند که سیستم با همان BIOS و بوت‌لودر بوت شود.

اگر مهاجمی سعی کند دیسک را به سیستم دیگری متصل کند یا از یک USB بوت کند، مقادیر PCR متفاوت خواهند را رمزنگاری کرده و فقط زمانی آن را رمزگشایی می‌کند که سیستم با همان BIOS و بوت‌لودر بوت شود.

اگر مهاجمی سعی کند دیسک را به سیستم دیگری متصل کند یا از یک USB بوت کند، مقادیر PCR متفاوت خواهند بود و TPM از رمزگشایی کلید خودداری می‌کند. این مکانیزم محافظت قدرتمندی در برابر حملات فیزیکی مانند سرقت هارد دیسک ایجاد می‌کند.

Sealing همچنین می‌تواند با احراز هویت کاربر ترکیب شود. برای باز کردن داده Sealed، هم PCRها باید مقادیر صحیح داشته باشند و هم کاربر باید رمز عبور یا بیومتریک صحیح را ارائه دهد. این رویکرد دو لایه امنیتی ایجاد می‌کند: یکی بر اساس وضعیت سیستم و دیگری بر اساس هویت کاربر.

یکی از کاربردهای نوین Sealing در Confidential Computing است. دستگاه‌های ابری می‌توانند با استفاده از TPM، محیط اجرایی امنی ایجاد کنند که داده‌های حساس تنها در یک پیکربندی خاص سخت‌افزاری و نرم‌افزاری قابل دسترسی باشند. این قابلیت برای پردازش داده‌های محرمانه در ابرهای عمومی اهمیت زیادی دارد.

یکپارچگی TPM با استاندارد FIDO

استاندارد FIDO (Fast IDentity Online) برای جایگزینی رمزهای عبور با روش‌های احراز هویت امن‌تر طراحی شده است. FIDO بر اساس رمزنگاری کلید عمومی عمل می‌کند: کاربر یک جفت کلید عمومی/خصوصی دارد که کلید خصوصی در دستگاه کاربر محفوظ است و هرگز به سرور ارسال نمی‌شود. احراز هویت با TPM به عنوان محل ایده‌آل برای ذخیره این کلیدهای خصوصی FIDO عمل می‌کند.

در معماری FIDO، مفهوم Authenticator وجود دارد که می‌تواند یک دستگاه سخت‌افزاری جداگانه (مانند کلید امنیتی USB) یا یک قابلیت داخلی دستگاه (مانند TPM) باشد. TPM می‌تواند به عنوان یک Platform Authenticator عمل کند و عملیات رمزنگاری FIDO را به طور مستقیم انجام دهد.

زمانی که کاربر می‌خواهد برای اولین بار با FIDO ثبت‌نام کند (Enrollment)، مرورگر یا اپلیکیشن از TPM می‌خواهد یک جفت کلید جدید تولید کند. TPM یک کلید خصوصی تولید کرده و آن را در حافظه خود ذخیره می‌کند. کلید عمومی به سرور ارسال می‌شود و سرور آن را با اکانت کاربر مرتبط می‌کند.

در فرآیند احراز هویت (Authentication)، سرور یک چالش تصادفی (challenge) به کلاینت ارسال می‌کند. کلاینت از TPM می‌خواهد این چالش را با کلید خصوصی ذخیره شده امضا کند. TPM امضای دیجیتال را ایجاد کرده و به کلاینت برمی‌گرداند. کلاینت این امضا را به سرور ارسال می‌کند و سرور با استفاده از کلید عمومی ذخیره شده، صحت امضا را تأیید می‌کند. اگر امضا معتبر باشد، سرور می‌داند که کاربر مالک کلید خصوصی است و او را احراز هویت می‌کند.

نقش TPM در احراز کننده‌های FIDO2

FIDO2 شامل دو استاندارد اصلی است: WebAuthn که یک API مرورگر است و CTAP (Client to Authenticator Protocol) که پروتکل ارتباط بین کلاینت و Authenticator است. TPM می‌تواند هر دو نقش Platform Authenticator و External Authenticator را ایفا کند.

به عنوان Platform Authenticator، TPM مستقیماً با سیستم‌عامل و مرورگر ادغام می‌شود. در ویندوز 10 و 11، Microsoft از TPM برای پیاده‌سازی Windows Hello استفاده می‌کند. Windows Hello یک سیستم احراز هویت بیومتریک است که از اثر انگشت یا تشخیص چهره برای احراز هویت کاربر استفاده می‌کند. کلیدهای خصوصی مرتبط با Windows Hello در TPM ذخیره می‌شوند و هر بار که کاربر با بیومتریک خود احراز هویت می‌شود، TPM عملیات رمزنگاری لازم را انجام می‌دهد.

یکپارچگی TPM با WebAuthn به این معنی است که وب‌سایت‌ها می‌توانند مستقیماً از TPM برای احراز هویت استفاده کنند. زمانی که کاربر به یک سایت که از FIDO2 پشتیبانی می‌کند مراجعه می‌نماید، مرورگر می‌تواند از TPM بخواهد که یک اعتبارنامه جدید (Credential) ایجاد کند. این فرآیند بدون نیاز به نصب نرم‌افزار اضافی یا استفاده از دستگاه خارجی انجام می‌شود.

TPM به عنوان Authenticator سطح L2+

FIDO Alliance سه سطح تأیید (Certification Level) برای Authenticatorها تعریف کرده است: L1، L2 و L3. سطح L1 برای Authenticatorهایی است که امنیت نرم‌افزاری دارند، L2 برای آنهایی که از محیط اجرایی امن استفاده می‌کنند و L3 برای Authenticatorهای سخت‌افزاری مقاوم در برابر دستکاری.

TPM معمولاً در دسته L2 یا L2+ قرار می‌گیرد. چرا که TPM یک محیط اجرایی ایزوله است که کلیدها را به صورت امن ذخیره می‌کند، اما لزوماً در برابر تمام حملات فیزیکی پیشرفته مقاوم نیست. dTPMهای با کیفیت بالا ممکن است ویژگی‌های نزدیک به L3 داشته باشند، اما اکثر TPMها به دلیل محدودیت‌های هزینه و طراحی، در سطح L2 باقی می‌مانند.

با این حال، برای اکثر کاربردهای سازمانی، سطح L2 کافی است. TPM محافظت مناسبی در برابر حملات نرم‌افزاری و بسیاری از حملات فیزیکی ارائه می‌دهد. سازمان‌هایی که نیاز به بالاترین سطح امنیت دارند (مانند نهادهای مالی یا دولتی)، می‌توانند از کلیدهای امنیتی سخت‌افزاری جداگانه با سطح L3 در کنار TPM استفاده کنند.

یکی از مزایای استفاده از TPM به عنوان FIDO Authenticator، یکپارچگی با سیاست‌های سازمانی است. مدیران IT می‌توانند از طریق Group Policy یا Mobile Device Management (MDM) سیاست‌های استفاده از TPM را اعمال کنند. به عنوان مثال، می‌توانند تعیین کنند که تمام اعتبارنامه‌های FIDO باید در TPM ذخیره شوند و از Attestation برای تأیید صحت دستگاه استفاده شود.

مزایای ترکیب TPM و WebAuthn

ترکیب TPM و WebAuthn مزایای متعددی برای کاربران و سازمان‌ها به همراه دارد. اول، سادگی تجربه کاربری است. کاربر نیازی به حمل کلید امنیتی جداگانه یا نصب نرم‌افزار خاصی ندارد. تنها با استفاده از بیومتریک دستگاه خود (اثر انگشت یا تشخیص چهره) می‌تواند به وب‌سایت‌ها و سرویس‌ها دسترسی پیدا کند.

دوم، امنیت بالا است. کلید خصوصی هرگز از TPM خارج نمی‌شود و در نتیجه حتی اگر سیستم‌عامل یا مرورگر آلوده باشد، مهاجم نمی‌تواند کلید را سرقت کند. علاوه بر این، استفاده از Remote Attestation امکان تأیید صحت دستگاه را قبل از احراز هویت فراهم می‌کند.

سوم، مدیریت متمرکز است. در محیط‌های سازمانی، مدیران می‌توانند سیاست‌هایی تعریف کنند که کاربران تنها با استفاده از TPM به منابع حساس دسترسی پیدا کنند. این سیاست‌ها می‌توانند بر اساس نقش کاربر، حساسیت داده یا موقعیت جغرافیایی متفاوت باشند.

چهارم، سازگاری با استانداردهای موجود است. TPM و WebAuthn هر دو استانداردهای باز و پذیرفته شده بین‌المللی هستند. بنابراین، راهکارهایی که بر اساس این فناوری‌ها ساخته می‌شوند، با طیف وسیعی از دستگاه‌ها، مرورگرها و سرویس‌ها سازگار هستند.

کاربردهای عملی TPM در سیستم‌های مدرن

TPM در بسیاری از سیستم‌های امروزی نقش کلیدی ایفا می‌کند. از احراز هویت کاربران گرفته تا محافظت از داده‌های ذخیره شده، TPM به عنوان یک لایه امنیتی پایه‌ای عمل می‌کند. در این بخش، سه کاربرد اصلی TPM را بررسی می‌کنیم که مستقیماً بر تجربه کاربران و امنیت سازمان‌ها تأثیر می‌گذارند.

Windows Hello محبوب‌ترین کاربرد احراز هویت با TPM است. این سیستم به کاربران اجازه می‌دهد تا به جای رمز عبور، از اثر انگشت یا تشخیص چهره برای ورود به ویندوز استفاده کنند. زمانی که کاربر اولین بار Windows Hello را راه‌اندازی می‌کند، سیستم یک جفت کلید در TPM تولید می‌کند. الگوی بیومتریک کاربر (template) نیز به صورت رمزشده در سیستم ذخیره می‌شود، اما کلید رمزگشایی آن در TPM محفوظ است.

هنگام ورود، سنسور بیومتریک الگوی کاربر را می‌خواند و با الگوی ذخیره شده مقایسه می‌کند. اگر تطابق داشته باشد، Windows از TPM می‌خواهد که یک توکن احراز هویت امضا کند. این توکن به Active Directory یا Azure AD ارسال می‌شود و سیستم کاربر را وارد می‌کند. تمام اینورود، سنسور بیومتریک الگوی کاربر را می‌خواند و با الگوی ذخیره شده مقایسه می‌کند. اگر تطابق داشته باشد، Windows از TPM می‌خواهد که یک توکن احراز هویت امضا کند. این توکن به Active Directory یا Azure AD ارسال می‌شود و سیستم کاربر را وارد می‌کند. تمام این فرآیند در کمتر از یک ثانیه انجام می‌شود و کاربر تجربه ای روان و سریع دارد.

Windows Hello و احراز هویت بیومتریک

Windows Hello از TPM برای محافظت در برابر حملات مختلف استفاده می‌کند. یکی از این حملات، Replay Attack است که مهاجم سعی می‌کند یک توکن احراز هویت قبلی را دوباره ارسال کند. TPM با استفاده از counter و nonce اطمینان می‌دهد که هر توکن فقط یک بار قابل استفاده است.

حمله دیگر، Man-in-the-Middle است که مهاجم ممکن است بخواهد در مسیر ارتباط بین کلاینت و سرور قرار گیرد. Windows Hello از مبادله کلید Diffie-Hellman و گواهینامه TPM برای ایجاد یک کانال امن استفاده می‌کند که جلوی این حملات را می‌گیرد.

Windows Hello همچنین از Anti-Spoofing پشتیبانی می‌کند. برای جلوگیری از اینکه مهاجم با استفاده از عکس یا ماسک، سیستم تشخیص چهره را فریب دهد، Windows Hello از دوربین‌های مادون قرمز و سنسورهای عمق استفاده می‌کند. این سنسورها می‌توانند تشخیص دهند که آیا یک چهره واقعی در مقابل دوربین است یا یک تصویر.

یکپارچگی Windows Hello با TPM به مدیران IT امکان می‌دهد سیاست‌های امنیتی سختگیرانه‌تری اعمال کنند. به عنوان مثال، می‌توانند تعیین کنند که تنها دستگاه‌هایی که TPM فعال دارند بتوانند از Windows Hello استفاده کنند. همچنین، می‌توانند Attestation را فعال کنند تا سرور بتواند تأیید کند که کلید بیومتریک واقعاً در TPM ذخیره شده و نه در نرم‌افزار.

BitLocker و رمزنگاری دیسک کامل

BitLocker ابزار رمزنگاری دیسک در ویندوز است که از TPM برای محافظت از کلید رمزنگاری استفاده می‌کند. زمانی که BitLocker فعال می‌شود، سیستم یک کلید رمزنگاری AES-256 تولید کرده و تمام داده‌های دیسک را با این کلید رمزنگاری می‌کند. اما خود کلید رمزنگاری باید به طریقی امن نگهداری شود تا در صورت راه‌اندازی سیستم قابل دسترسی باشد.

TPM این مشکل را با استفاده از Sealing حل می‌کند. کلید BitLocker به مقادیر PCR خاصی Seal می‌شود که نشان‌دهنده وضعیت سالم سیستم هستند. هر بار که سیستم بوت می‌شود، TPM مقادیر فعلی PCR را بررسی کرده و تنها در صورتی که با مقادیر Seal شده مطابقت داشته باشند، کلید را آزاد می‌کند.

اگر مهاجمی سعی کند دیسک رمزشده را به سیستم دیگری متصل کند یا از یک USB بوت کند، مقادیر PCR متفاوت خواهند بود و TPM از آزاد کردن کلید خودداری می‌کند. در نتیجه، مهاجم نمی‌تواند به داده‌های دیسک دسترسی پیدا کند حتی اگر دیسک را فیزیکی در اختیار داشته باشد.

BitLocker همچنین می‌تواند با احراز هویت کاربر ترکیب شود. در حالت پیش‌فرض، اگر TPM وجود داشته باشد، BitLocker به صورت شفاف عمل می‌کند و کاربر متوجه رمزنگاری نمی‌شود. اما مدیران می‌توانند تنظیم کنند که برای بوت سیستم، کاربر باید یک PIN وارد کند یا یک کلید USB خاص را وصل نماید. این رویکرد لایه امنیتی اضافی ایجاد می‌کند.

Secure Boot و زنجیره اعتماد بوت

Secure Boot مکانیزمی در UEFI است که اطمینان می‌دهد تنها کدهای امضا شده و مورد اعتماد در طول فرآیند بوت اجرا شوند. TPM نقش کلیدی در تکمیل Secure Boot ایفا می‌کند. در حالی که Secure Boot جلوی اجرای کدهای غیرمجاز را می‌گیرد، TPM وضعیت سیستم پس از بوت را ثبت می‌کند تا بتوان آن را تأیید کرد.

فرآیند Measured Boot به این صورت است که UEFI قبل از اجرای هر جزء، هش آن جزء را محاسبه کرده و در PCR مربوطه ثبت می‌کند. این فرآیند از فریم‌ور UEFI شروع می‌شود و تا بوت‌لودر، کرنل، درایورها و حتی برنامه‌های بارگذاری شده در Startup ادامه می‌یابد. در پایان، یک لاگ کامل از تمام کدهایی که در طول بوت اجرا شده‌اند در سیستم موجود است.

این لاگ می‌تواند به سرویس‌های Remote Attestation ارسال شود. به عنوان مثال، Microsoft Intune می‌تواند لاگ بوت را دریافت کرده و تجزیه‌وتحلیل کند. اگر Intune تشخیص دهد که یک درایور مشکوک یا بدافاری شده در Startup ادامه می‌یابد. در پایان، یک لاگ کامل از تمام کدهایی که در طول بوت اجرا شده‌اند در سیستم موجود است.

این لاگ می‌تواند به سرویس‌های Remote Attestation ارسال شود. به عنوان مثال، Microsoft Intune می‌تواند لاگ بوت را دریافت کرده و تجزیه‌وتحلیل کند. اگر Intune تشخیص دهد که یک درایور مشکوک یا بدافزار در طول بوت اجرا شده، می‌تواند دسترسی آن دستگاه به منابع سازمانی را مسدود کند.

ترکیب Secure Boot و TPM یک زنجیره اعتماد ایجاد می‌کند که از فریم‌ور تا سطح اپلیکیشن ادامه دارد. هر لایه، لایه بعدی را تأیید می‌کند و TPM تاریخچه کامل این تأییدها را ثبت می‌کند. این معماری اطمینان می‌دهد که سیستم از یک حالت شناخته شده شروع شده و در طول بوت هیچ دستکاری نشده است.

TPM در محیط‌های سازمانی و Enterprise

سازمان‌ها برای مدیریت امنیت دستگاه‌های کاری، نیاز به ابزارهایی دارند که بتوانند سیاست‌های امنیتی را به صورت متمرکز اعمال و نظارت کنند. TPM با فراهم کردن قابلیت‌های مدیریتی، به یکی از ارکان اصلی امنیت Enterprise تبدیل شده است.

Group Policy در Active Directory ابزاری است که مدیران می‌توانند با آن تنظیمات سیستم‌ها را از راه دور مدیریت کنند. مایکروسافت مجموعه‌ای از سیاست‌های مخصوص TPM را ارائه کرده که شامل تنظیماتی مانند فعال‌سازی TPM، تنظیم سیاست‌های مالکیت، پیکربندی BitLocker و مدیریت گواهینامه‌های TPM است.

یکی از سیاست‌های مهم، الزام به فعال بودن TPM است. مدیران می‌توانند تعریف کنند که تمام دستگاه‌های سازمان باید TPM فعال داشته باشند و در غیر این صورت، به شبکه متصل نشوند. این سیاست اطمینان می‌دهد که تمام دستگاه‌های سازمانی از لایه امنیتی سخت‌افزاری برخوردارند.

مدیریت متمرکز TPM با Group Policy

Group Policy می‌تواند تنظیمات BitLocker را نیز مدیریت کند. به عنوان مثال، مدیران می‌توانند تعیین کنند که تمام دیسک‌های سیستم باید با BitLocker رمزنگاری شوند و کلید رمزنگاری باید در TPM ذخیره شود. همچنین، می‌توانند سیاست بازیابی را تنظیم کنند: اگر کاربری رمز عبور خود را فراموش کرد یا TPM دچار مشکل شد، کلید بازیابی (Recovery Key) باید در Active Directory یا Azure AD ذخیره شود تا مدیران بتوانند در صورت نیاز دسترسی را بازگردانند.

یکی دیگر از قابلیت‌های مدیریتی، Endorsement Key (EK) Certificate است. هر TPM یک کلید خصوصی یکتا دارد که در کارخانه تولید شده و هرگز قابل تغییر نیست. گواهینامه EK این کلید را تأیید می‌کند و نشان می‌دهد که TPM اصلی است. مدیران می‌توانند از این گواهینامه برای احراز هویت دستگاه‌ها استفاده کنند.

در سناریوهای پیشرفته‌تر، سازمان‌ها ممکن است از Attestation Identity Key (AIK) Certificates استفاده کنند. این گواهینامه‌ها توسط یک CA (Certificate Authority) سازمانی صادر می‌شوند و به TPMها اجازه می‌دهند که به نمایندگی از دستگاه، در فرآیندهای Attestation شرکت کنند. مدیریت این گواهینامه‌ها از طریق PKI سازمانی صورت می‌گیرد.

TPM در سناریوهای Zero Trust

مدل Zero Trust بر این اصل استوار است که “هیچ‌چیز را به طور پیش‌فرض اعتماد نکنید و همیشه تأیید کنید”. در این مدل، دسترسی به منابع بر اساس هویت کاربر، وضعیت دستگاه و سیاست‌های امنیتی تصمیم‌گیری می‌شود. TPM نقش کلیدی در اجرای Zero Trust ایفا می‌کند زیرا امکان تأیید وضعیت دستگاه را فراهم می‌آورد.

در یک سناریوی Zero Trust، زمانی که کاربر تلاش می‌کند به یک منبع حساس دسترسی پیدا کند، سیستم ابتدا هویت کاربر را تأیید می‌کند (معمولاً با MFA). سپس، وضعیت دستگاه کاربر را بررسی می‌کند. سیستم از TPM درخواست می‌کند که یک Quote شامل مقادیر PCR ارسال کند. این Quote نشان می‌دهد که آیا دستگاه با Secure Boot راه‌اندازی شده، آیا BitLocker فعال است، آیا آنتی‌ویروس به‌روز است و آیا هیچ بدافزاری شناسایی نشده است.

بر اساس نتیجه این ارزیابی، سیستم سطح اعتماد (Trust Score) دستگاه را محاسبه می‌کند. اگر سطح اعتماد بالا باشد، کاربر دسترسی کامل دریافت می‌کند. اگر سطح اعتماد متوسط باشد، ممکن است دسترسی محدود یا نیاز به احراز هویت مجدد وجود داشته باشد. اگر سطح اعتماد پایین باشد، دسترسی کاملاً مسدود می‌شود و دستگاه باید توسط تیم IT بررسی شود.

Device Health Attestation در Azure AD

Microsoft Device Health Attestation (DHA) را به عنوان بخشی از Azure AD ارائه کرده است. DHA از TPM برای جمع‌آوری شواهدی از وضعیت امنیتی دستگاه استفاده می‌کند و این شواهد را به سرویس ابری ارسال می‌نماید. سرویس ابری این شواهد را تجزیه‌وتحلیل کرده و تأیید می‌کند که دستگاه سالم است.

فرآیند DHA به این صورت است که پس از بری ارسال می‌نماید. سرویس ابری این شواهد را تجزیه‌وتحلیل کرده و تأیید می‌کند که دستگاه سالم است.

فرآیند DHA به این صورت است که پس از بوت دستگاه، یک Agent روی ویندوز مقادیر PCR و لاگ بوت را از TPM دریافت کرده و به سرویس DHA ارسال می‌کند. سرویس DHA این داده‌ها را با سیاست‌های امنیتی سازمان مقایسه کرده و یک Health Certificate صادر می‌کند که معتبر است تا زمانی که دستگاه دوباره راه‌اندازی شود.

Conditional Access در Azure AD می‌تواند از این Health Certificate استفاده کند. به عنوان مثال، سیاست تعریف می‌شود: “تنها دستگاه‌هایی که Health Certificate معتبر دارند می‌توانند به Microsoft 365 دسترسی پیدا کنند.” این سیاست اطمینان می‌دهد که کاربرانی که دستگاه‌های آلوده یا دستکاری شده دارند، نمی‌توانند به داده‌های سازمانی دسترسی پیدا کنند.

DHA همچنین می‌تواند در سناریوهای BYOD (Bring Your Own Device) استفاده شود. سازمان‌ها ممکن است اجازه دهند کارمندان با دستگاه‌های شخصی خود به برخی منابع دسترسی داشته باشند، اما با شرط اینکه دستگاه شرایط امنیتی مشخصی را داشته باشد. TPM و DHA امکان تأیید این شرایط را فراهم می‌آورند بدون اینکه کنترل کامل دستگاه به سازمان واگذار شود.

نشانه و پیاده‌سازی احراز هویت مبتنی بر TPM

نشانه (محصول شرکت رهسا) یک سامانه یکپارچه مدیریت دسترسی و هویت (IAM) است که قابلیت‌های پیشرفته احراز هویت مبتنی بر FIDO و TPM را ارائه می‌دهد. نشانه به سازمان‌های ایرانی امکان می‌دهد تا از جدیدترین استانداردهای امنیتی جهانی بهره‌مند شوند و در عین حال نیازهای خاص محلی را برآورده کنند.

معماری نشانه به گونه‌ای طراحی شده که می‌تواند با TPM دستگاه‌های کاربران یکپارچه شود و از آن به عنوان یک لایه امنیتی سخت‌افزاری استفاده کند. زمانی که کاربر برای اولین بار به سامانه نشانه متصل می‌شود، سیستم وجود TPM را بررسی کرده و در صورت فعال بودن، از TPM برای تولید کلیدهای احراز هویت استفاده می‌کند.

نشانه از استاندارد FIDO2/WebAuthn پشتیبانی کامل می‌کند و می‌تواند با TPM به عنوان Platform Authenticator کار کند. این یعنی کاربران می‌توانند بدون نیاز به کلید امنیتی جداگانه، تنها با استفاده از بیومتریک دستگاه خود (اثر انگشت یا تشخیص چهره) به سامانه‌های سازمانی دسترسی پیدا کنند.

معماری یکپارچه نشانه با TPM

سامانه نشانه شامل چند جزء اصلی است: سرور IAM، پایگاه داده کاربران، سرور FIDO، و کلاینت‌های کاربر. جزء کلاینت می‌تواند اپلیکیشن وب در مرورگر، اپلیکیشن موبایل یا نرم‌افزار دسکتاپ باشد. هر یک از این کلاینت‌ها می‌توانند با TPM دستگاه خود ارتباط برقرار کنند.

زمانی که کاربر برای اولین بار ثبت‌نام می‌کند، فرآیند به این صورت است:

مرحله اول، سرور نشانه یک چالش ثبت‌نام (Registration Challenge) به کلاینت ارسال می‌کند. این چالش شامل یک nonce تصادفی، شناسه کاربر و سیاست‌های مورد نیاز (مانند نوع کلید، الگوریتم رمزنگاری) است.

مرحله دوم، کلاینت از TPM می‌خواهد یک جفت کلید جدید تولید کند. TPM ک TPM

سامانه نشانه شامل چند جزء اصلی است: سرور IAM، پایگاه داده کاربران، سرور FIDO، و کلاینت‌های کاربر. جزء کلاینت می‌تواند اپلیکیشن وب در مرورگر، اپلیکیشن موبایل یا نرم‌افزار دسکتاپ باشد. هر یک از این کلاینت‌ها می‌توانند با TPM دستگاه خود ارتباط برقرار کنند.

زمانی که کاربر برای اولین بار ثبت‌نام می‌کند، فرآیند به این صورت است:

مرحله اول، سرور نشانه یک چالش ثبت‌نام (Registration Challenge) به کلاینت ارسال می‌کند. این چالش شامل یک nonce تصادفی، شناسه کاربر و سیاست‌های مورد نیاز (مانند نوع کلید، الگوریتم رمزنگاری) است.

مرحله دوم، کلاینت از TPM می‌خواهد یک جفت کلید جدید تولید کند. TPM کلید خصوصی را در حافظه خود ذخیره کرده و کلید عمومی را به کلاینت برمی‌گرداند.

مرحله سوم، کلاینت از TPM می‌خواهد که یک Attestation Object ایجاد کند. این Object شامل کلید عمومی، مشخصات TPM (مدل، نسخه، سازنده) و امضای دیجیتال TPM است که صحت این اطلاعات را تأیید می‌کند.

مرحله چهارم، کلاینت Attestation Object را به همراه پاسخ چالش به سرور ارسال می‌کند. سرور امضای TPM را بررسی کرده و اطمینان حاصل می‌کند که کلید واقعاً در یک TPM معتبر تولید شده است.

مرحله پنجم، سرور کلید عمومی را با شناسه کاربر مرتبط کرده و در پایگاه داده ذخیره می‌کند. از این پس، کاربر می‌تواند با استفاده از این کلید احراز هویت شود.

نشانه موبایل و استفاده از TPM گوشی‌های اندروید

گوشی‌های هوشمند اندروید مدرن نیز دارای TPM یا معادل آن هستند. در اندروید، این قابلیت معمولاً به صورت Hardware-backed Keystore پیاده‌سازی شده که از TEE (Trusted Execution Environment) یا Secure Element استفاده می‌کند. عملکرد آن شبیه TPM است: کلیدها در محیط امن ذخیره می‌شوند و عملیات رمزنگاری درون آن محیط انجام می‌پذیرد.

نشانه موبایل اپلیکیشنی است که بر روی گوشی کاربر نصب می‌شود و از Keystore سخت‌افزاری دستگاه برای ذخیره کلیدهای احراز هویت استفاده می‌کند. زمانی که کاربر می‌خواهد به یک سرویس دسترسی پیدا کند، نشانه موبایل از او می‌خواهد که با بیومتریک (اثر انگشت یا تشخیص چهره) خود را تأیید کند. پس از تأیید، نشانه موبایل از Keystore می‌خواهد که چالش سرور را امضا کند و امضا را ارسال می‌کند.

مزیت اصلی استفاده از نشانه موبایل، قابلیت حمل است. کاربر می‌تواند گوشی خود را همیشه همراه داشته باشد و در هر مکانی که نیاز است، احراز هویت انجام دهد. همچنین، نشانه موبایل می‌تواند برای Passwordless MFA استفاده شود: کاربر نام کاربری خود را در کامپیوتر وارد می‌کند، سپس یک اعلان push به گوشی او ارسال می‌شود و او با یک لمس، احراز هویت را تأیید می‌نماید.

کلیدهای امنیتی نشانه با پشتیبانی TPM

علاوه بر نشانه موبایل، شرکت رهسا کلیدهای امنیتی سخت‌افزاری (نشانه توکن) نیز ارائه می‌دهد که می‌توانند از طریق USB یا NFC به دستگاه متصل شوند. این کلیدها معمولاً دارای یک تراشه رمزنگاری داخلی هستند که شبیه به TPM عمل می‌کند.

کلیدهای امنیتی نشانه با استاندارد FIDO2 سازگار هستند و می‌توانند در هر سیستمی که از WebAuthn پشتیبانی می‌کند، استفاده شوند. این کلیدها برای کاربرانی مناسب هستند که نیاز به بالاترین سطح امنیت دارند یا در محیط‌هایی کار می‌کنند که استفاده از گوشی شخصی مجاز نیست.

ترکیب TPM داخلی دستگاه، نشانه موبایل و کلید امنیتی سخت‌افزاری، یک راهکار چندلایه امنیتی ایجاد می‌کند. سازمان‌ها می‌توانند بر اساس سطح دسترسی کاربر، تعیین کنند که کدام روش احراز هویت باید استفاده شود. به عنوان مثال، کاربران عادی می‌توانند با TPM لپ‌تاپ خود احراز هویت کنند، اما کاربران با دسترسی به سیستم‌های حساس باید از کلید امنیتی سخت‌افزاری استفاده کنند.

چالش‌ها و محدودیت‌های TPM

با وجود مزایای متعدد، TPM محدودیت‌ها و چالش‌هایی نیز دارد که باید در نظر گرفته شوند. درک این محدودیت‌ها به سازمان‌ها کمک می‌کند تا راهکارهای مکمل را پیاده‌سازی کنند و از TPM به بهترین شکل استفاده کنند.

یکی از مشکلات اصلی، سازگاری است. همه دستگاه‌ها TPM ندارند، به ویژه دستگاه‌های قدیمی‌تر یا ارزان‌قیمت. حتی اگر TPM وجود داشته باشد، ممکن است نسخه قدیمی (TPM 1.2) باشد که قابلیت‌های محدودی دارد. علاوه بر این، در برخی سیستم‌ها TPM به صورت پیش‌فرض غیرفعال است و نیاز به فعال‌سازی دستی در BIOS/UEFI دارد.

پشتیبانی سیستم‌عامل نیز یک چالش است. در حالی که ویندوز 10 و 11 پشتیبانی کامل از TPM دارند، سیستم‌عامل‌های دیگر مانند لینوکس و macOS ممکن است نیاز به پیکربندی دستی داشته باشند. در لینوکس، کاربر باید درایورهای TPM را نصب کرده و ابزارهایی مانند tpm2-tools را برازگاری** است. همه دستگاه‌ها TPM ندارند، به ویژه دستگاه‌های قدیمی‌تر یا ارزان‌قیمت. حتی اگر TPM وجود داشته باشد، ممکن است نسخه قدیمی (TPM 1.2) باشد که قابلیت‌های محدودی دارد. علاوه بر این، در برخی سیستم‌ها TPM به صورت پیش‌فرض غیرفعال است و نیاز به فعال‌سازی دستی در BIOS/UEFI دارد.

پشتیبانی سیستم‌عامل نیز یک چالش است. در حالی که ویندوز 10 و 11 پشتیبانی کامل از TPM دارند، سیستم‌عامل‌های دیگر مانند لینوکس و macOS ممکن است نیاز به پیکربندی دستی داشته باشند. در لینوکس، کاربر باید درایورهای TPM را نصب کرده و ابزارهایی مانند tpm2-tools را برای تعامل با TPM استفاده کند.

مشکلات سازگاری و پشتیبانی سیستم‌عامل

یکی دیگر از مشکلات، پیچیدگی مدیریت است. TPM APIهای سطح پایینی دارد و کار مستقیم با آن نیازمند دانش فنی عمیق است. توسعه‌دهندگان نرم‌افزار باید با مفاهیمی مانند سلسله مراتب کلید، سیاست‌های Authorization و PCR Extension آشنا باشند. این پیچیدگی می‌تواند مانعی برای پذیرش گسترده باشد.

برای حل این مشکل، کتابخانه‌ها و چارچوب‌های سطح بالاتری مانند Microsoft TPM Platform Crypto Provider و OpenSSL TPM Engine ایجاد شده‌اند که پیچیدگی‌ها را پنهان می‌کنند. همچنین، استاندارد FIDO با ارائه یک لایه abstraction، تعامل با TPM را برای کاربردهای احراز هویت ساده‌تر کرده است.

عملکرد نیز می‌تواند یک محدودیت باشد. TPM برای عملیات رمزنگاری سنگین طراحی نشده و سرعت آن کمتر از پردازنده‌های اصلی است. به عنوان مثال، تولید یک جفت کلید RSA 2048 بیتی در TPM ممکن است چند صد میلی‌ثانیه طول بکشد، در حالی که همین عملیات روی CPU اصلی در کمتر از 10 میلی‌ثانیه انجام می‌شود. بنابراین، TPM برای عملیات متداول مناسب نیست، بلکه برای عملیات کلیدی که ام پیچیدگی‌ها را پنهان می‌کنند. همچنین، استاندارد FIDO با ارائه یک لایه abstraction، تعامل با TPM را برای کاربردهای احراز هویت ساده‌تر کرده است.

عملکرد نیز می‌تواند یک محدودیت باشد. TPM برای عملیات رمزنگاری سنگین طراحی نشده و سرعت آن کمتر از پردازنده‌های اصلی است. به عنوان مثال، تولید یک جفت کلید RSA 2048 بیتی در TPM ممکن است چند صد میلی‌ثانیه طول بکشد، در حالی که همین عملیات روی CPU اصلی در کمتر از 10 میلی‌ثانیه انجام می‌شود. بنابراین، TPM برای عملیات متداول مناسب نیست، بلکه برای عملیات کلیدی که امنیت در آنها اولویت دارد استفاده می‌شود.

حملات فیزیکی و Side-Channel

TPM در برابر حملات نرم‌افزاری مقاوم است، اما در برابر حملات فیزیکی آسیب‌پذیری‌هایی دارد. یک مهاجم با دسترسی فیزیکی به دستگاه می‌تواند سعی کند از طریق تجزیه و تحلیل سیگنال‌های الکتریکی (مانند توان مصرفی یا تابش الکترومغناطیسی)، اطلاعاتی از TPM استخراج کند. این حملات که Side-Channel نامیده می‌شوند، نیازمند تجهیزات پیشرفته و تخصص بالا هستند، اما امکان‌پذیرند.

برای مقابله با Side-Channel، TPMهای با کیفیت بالا از تکنیک‌هایی مانند Random Delay، Dummy Operations و Shielding استفاده می‌کنند که جمع‌آوری اطلاعات را دشوارتر می‌کند. همچنین، TPMهای سطح L3 (که معمولاً دارای گواهینامه Common Criteria EAL4+ هستند) در برابر این حملات مقاوم‌تر طراحی شده‌اند.

حمله دیگر، Bus Sniffing است که مهاجم ممکن است سعی کند ارتباط بین TPM و پردازنده اصلی را رهگیری کند. در dTPM، این ارتباط معمولاً از طریق باس LPC یا SPI انجام می‌شود. اگر داده‌ها بدون رمزنگاری منتقل شوند، مهاجم می‌تواند آنها را بخواند. برای جلوگیری از این حمله، برخی پیاده‌سازی‌ها از Session Encryption استفاده می‌کنند که تمام ارتباطات بین TPM و Host را رمزنگاری می‌کند.

مدیریت بازیابی و پشتیبان‌گیری کلیدها

یکی از چالش‌های اصلی در استفاده از TPM، بازیابی در صورت خرابی است. اگر TPM دچار نقص سخت‌افزاری شود یا مادربرد تعویض گردد، کلیدهای ذخیره شده در TPM از دست خواهند رفت. چون کلیدها هرگز از TPM خارج نمی‌شوند، امکان پشتیبان‌گیری مستقیم وجود ندارد.

راه‌حل این مشکل، استفاده از Recovery Keys است. به عنوان مثال، BitLocker یک کلید بازیابی 48 رقمی تولید می‌کند که کاربر باید آن را چاپ کرده یا در یک مکان امن ذخیره کند. اگر TPM خراب شود، کاربر می‌تواند با وارد کردن این کلید بازیابی، به داده‌های رمزشده دسترسی پیدا کند.

برای کلیدهای احراز هویت FIDO، راه‌حل، ثبت چندین Authenticator است. کاربر باید هم از TPM لپ‌تاپ خود و هم از نشانه موبایل و هم از یک کلید امنیتی سخت‌افزاری به عنوان Authenticator ثبت‌نام کند. به این ترتیب، اگر یکی از آنها از دست برود یا خراب شود، کاربر همچنان می‌تواند با سایر روش‌ها احراز هویت کند.

در محیط‌های سازمانی، Escrow Services می‌توانند راه‌حل باشند. در این سیستم، یک کپی رمزشده از کلیدها (که تنها با کلید مدیر سازمان قابل رمزگشایی است) در یک سرویس امن ذخیره می‌شود. اگر کاربری دستگاه خود را از دست بدهد، مدیر می‌تواند کلیدها را بازیابی کرده و به دستگاه جدید منتقل کند. البته این رویکرد باید با دقت پیاده‌سازی شود تا حریم خصوصی کاربر حفظ شود.

جمع‌بندی نهایی و توصیه‌های امنیتی

احراز هویت با TPM یک گام بنیادین در گذار از امنیت نرم‌افزاری به اعتماد سخت‌افزاری است. TPM با فراهم کردن:

• ریشه اعتماد سخت‌افزاری
• ذخیره امن کلیدها
• Attestation دستگاه
• یکپارچگی کامل با FIDO

به سازمان‌ها کمک می‌کند تا:

• رمزهای عبور را حذف کنند
• حملات فیشینگ را خنثی نمایند
• معماری Zero Trust را عملی کنند

توصیه نهایی نشانه

برای دستیابی به حداکثر امنیت:

• TPM لپ‌تاپ‌ها
• نشانه موبایل
• نشانه توکن سخت‌افزاری

را در یک معماری چندلایه احراز هویت ترکیب کنید.

🟦 مشاوره امنیتی رایگان