هویت دستگاه چیست؟ کلید خصوصی و نقش TPM
نام یک دستگاه را می‌توان کپی کرد. با مثال کنترل‌کنندهٔ آبیاری می‌بینیم کلید خصوصی چگونه به اثبات هویت کمک می‌کند و TPM چه چیزی را محافظت می‌کند.
فهرست مطالب
نام و شمارهٔ سریال یک دستگاه را می‌توان کپی کرد. برای اینکه یک سامانه مطمئن شود پیام از دستگاه ثبت‌شده آمده، دستگاه باید چیزی را ثابت کند که با کپی‌کردن نامش به دست نمی‌آید: در اختیار داشتن یک کلید محرمانه. TPM به نگهداری و استفادهٔ محافظت‌شده از این کلید کمک می‌کند؛ اما به‌تنهایی درستی برنامه یا مجازبودن هر فرمان را ثابت نمی‌کند.
یک کنترل‌کنندهٔ آبیاری را در نظر بگیرید؛ دستگاهی که شیر آب را باز و بسته می‌کند. این دستگاه گزارش کارش را به سرور می‌فرستد. سرور، رایانه‌ای است که پیام دستگاه‌ها را دریافت می‌کند و خدماتی مثل ثبت گزارش یا ارسال تنظیمات می‌دهد. اگر فرد دیگری نام دستگاه را روی رایانهٔ خودش بگذارد، سرور باید بتواند این دو را از هم تشخیص دهد.
شناسه می‌گوید «کدام دستگاه»؛ اثبات هویت می‌گوید «با چه مدرکی»
شناسه‌ای مانند irrigation-07 برای پیداکردن پروندهٔ دستگاه مفید است. مثل نام روی یک پاکت است: دانستن نام، مدرک مالکیت نیست. در این مثال، هنگام راه‌اندازی معتبر، سرور یک کلید عمومی را به همین پرونده وصل می‌کند. این ثبت اولیه باید قابل اعتماد باشد؛ اگر سرور کلید پیشنهادی هر فرستنده‌ای را بپذیرد، بررسی‌های بعدی هویت صاحب واقعی را ثابت نمی‌کنند.
کلید در اینجا دسته‌ای از داده‌هاست که در یک روش ریاضی برای امضا یا بررسی پیام به کار می‌رود. در روش امضای دیجیتال، دو کلید مرتبط داریم. کلید خصوصی باید نزد دستگاه محرمانه بماند؛ کلید عمومی را می‌توان به بررسی‌کننده داد. دستگاه با کلید خصوصی امضا می‌سازد و سرور با کلید عمومی، امضا را بررسی می‌کند. امضا نوشته‌ای شبیه امضای دست نیست و متن پیام را هم پنهان نمی‌کند.
چرا یک پاسخ قدیمی کافی نیست؟
فرض کنید دستگاه همیشه یک جملهٔ ثابت را امضا کند. کسی که یک پاسخ معتبر را ضبط کرده، ممکن است همان پاسخ را دوباره بفرستد. این کار را بازپخش می‌نامیم. برای جداکردن پاسخ تازه از پاسخ ضبط‌شده، سرور یک درخواست تازه و غیرقابل‌پیش‌بینی می‌سازد. عدد تصادفی این درخواست را معمولاً «نانس» می‌نامند؛ در این کاربرد قرار نیست یک درخواست معتبر دوباره پذیرفته شود.
در نمونهٔ فرضی ما، درخواست شامل نام دستگاه، نام خدمت مورد نظر، نانس و زمان پایان اعتبار است. دستگاه همهٔ این داده‌ها را با هم امضا می‌کند. سرور باید هم امضا را بررسی کند، هم مطمئن شود پاسخ مربوط به همان درخواست صادرشده است، هنوز منقضی نشده و قبلاً مصرف نشده است. این بررسی‌ها دلیل جداگانه دارند؛ معتبر بودن امضا به‌تنهایی جلوی بازپخش را نمی‌گیرد.
مثال آبیاری: چه چیزی پذیرفته یا رد می‌شود؟
برای فهم روند، مهلت پاسخ را فرضاً ۱۰ ثانیه می‌گذاریم. این عدد انتخاب آموزشی است؛ مهلت مناسب محصول به شبکه و طراحی سامانه بستگی دارد. برای درخواست A در ثانیهٔ صفر، این سه حالت را بررسی کنید:
| رویداد فرضی | نتیجه | دلیل |
|---|---|---|
| پاسخ دستگاه ثبت‌شده در ثانیهٔ ۲ | پذیرش یک‌باره | امضا درست است و درخواست هنوز باز است. |
| تکرار همان پاسخ در ثانیهٔ ۳ | رد | درخواست قبلاً مصرف شده است. |
| اولین پاسخ به درخواست تازهٔ B پس از ۱۲ ثانیه | رد | مهلت ۱۰ ثانیه‌ای گذشته است، حتی اگر امضا درست باشد. |
در تمرین آفلاین همراه درس، برای نانس ۱۶ بایت تصادفی می‌سازیم. هر بایت ۸ بیت دارد و هر بیت می‌تواند صفر یا یک باشد؛ پس ۱۶ بایت برابر ۱۲۸ بیت است و 2^128 ≈ 3.4 × 10^38 حالت دارد. اگر همهٔ حالت‌ها هم‌احتمال باشند، شانس حدس دقیق یک نانس در یک تلاش 1/2^128 است. این محاسبه فقط دربارهٔ حدس همان عدد است؛ احتمال نفوذ به کل سامانه یا قدرت امضا را بیان نمی‌کند. تولید امن عدد، ثبت درخواست و جلوگیری از استفادهٔ دوباره همچنان لازم‌اند.
TPM کجای این کار قرار می‌گیرد؟
TPM نام کوتاه Trusted Platform Module است؛ سازوکاری برای انجام برخی کارهای امنیتی، از جمله محافظت از کلیدها. در یک طراحی مناسب می‌توان کلیدی ساخت که بخش خصوصی آن از محیط محافظت‌شده بیرون نیاید و عملیات مجاز با همان‌جا انجام شود. «غیرقابل‌استخراج» بودن ویژگی هر کلید دلخواه نیست؛ نوع کلید، تنظیمات و پیاده‌سازی مهم‌اند.
TPM ممکن است قطعه‌ای جدا باشد یا در محیط محافظت‌شدهٔ سامانه پیاده شود. به نوع مبتنی بر firmware، یعنی نرم‌افزار سطح دستگاه، معمولاً fTPM می‌گویند. برای نمونه، راهنمای SEC-TPM وریسایت یک پیاده‌سازی مبتنی بر OP-TEE را توضیح می‌دهد؛ محیطی که بخشی از برنامه‌های حساس را از محیط عادی جدا می‌کند. همان راهنما می‌گوید این قابلیت در پیکربندی مستندش پس از بالا آمدن هستهٔ لینوکس در دسترس است. پس نباید آن را بدون بررسی، جایگزین همهٔ مراحل امنیت هنگام روشن‌شدن دانست.
اگر کلید خصوصی به‌جای فایل عادی در محیط محافظت‌شده باشد، کپی‌کردن فایل‌های دستگاه لزوماً آن کلید را در اختیار مهاجم نمی‌گذارد. بااین‌حال، برنامهٔ آلوده ممکن است بکوشد از عملیات مجاز کلید سوءاستفاده کند. کنترل دسترسی، به‌روزرسانی، لغو اعتبار دستگاه گم‌شده و نگهداری امن سرور همچنان بخشی از طراحی‌اند.
چهار سؤال متفاوت را با هم اشتباه نگیریم
- اثبات هویت: آیا پاسخ‌دهنده کلید مربوط به این دستگاه ثبت‌شده را در اختیار دارد؟
- مجوز: این دستگاه پس از شناسایی اجازهٔ انجام کدام کار را دارد؟ دستگاه یک مزرعه نباید تنظیمات مزرعهٔ دیگر را عوض کند.
- محرمانگی ارتباط: آیا شخص دیگری می‌تواند محتوای پیام را بخواند؟ ارتباط رمزگذاری‌شده با بررسی معتبر هویت دو طرف، مسئله‌ای جدا از امضای این مثال است.
- گواهی وضعیت یا attestation: آیا شواهد قابل بررسی از وضعیت راه‌اندازی یا محیط دستگاه داریم؟ پاسخ به این سؤال به اندازه‌گیری‌ها، زنجیرهٔ اعتماد و سیاست بررسی نیاز دارد؛ امضای یک نانس به‌تنهایی چنین گزارشی نیست.
تمرین اختیاری روی رایانه
برای دیدن تفاوت امضای درست، کلید اشتباه و پاسخ تکراری، فایل تمرین Python را اجرا کنید. پیش‌نیازش آشنایی با اجرای Python و نصب بستهٔ cryptography است. فایل فقط در همان فرایند کلید موقت می‌سازد و شش حالت را بررسی می‌کند؛ به شبکه یا TPM وصل نمی‌شود و کلیدی را ذخیره نمی‌کند. روش امضا Ed25519 است؛ این انتخاب به معنی پشتیبانی هر TPM از آن نیست.
python -m pip install cryptography==50.0.2
python identity_exercise.pyخروجی باید شش سطر PASS برای پاسخ معتبر، کلید اشتباه، تغییر محتوا، بازپخش، انقضا و شناسهٔ ناشناخته نشان دهد. این تمرین نرم‌افزاری، پروتکل آمادهٔ محصول یا آزمون امنیت TPM نیست. در محصول واقعی از پروتکل و پیاده‌سازی بررسی‌شده استفاده کنید؛ مدیریت هم‌زمانی، ارتباط امن و چرخهٔ عمر کلید در این فایل آموزشی پوشش داده نشده‌اند.
برای ادامه، امنیت BLE تفاوت شناسایی و مجوز در ارتباط نزدیک را بررسی می‌کند. مسیر یادگیری سیستم‌های امبدد هم جای نرم‌افزار و آزمون را در یک دستگاه توضیح می‌دهد.
منابع
پرسش و پاسخ مقاله
سوال فنی خود را مطرح کنید
پرسش‌ها و پاسخ‌ها پس از بررسی مدیر منتشر می‌شوند. نویسنده، پیش‌نویس در انتظار بررسی را می‌بیند.
هنوز پرسش تاییدشده‌ای برای این مقاله ثبت نشده است.