یک کلید، دو محل متفاوت برای نگهداری
اگر کلید خصوصی دستگاه در فایل تنظیمات یا حافظه قابل خواندن میکروکنترلر باشد، تهیه نسخه از همان حافظه می‌تواند کلید را هم تکثیر کند. برد ATECC608 آدافروت با شناسه ۴۳۱۴ امکان آزمایش معماری دیگری را می‌دهد. عملیات رمزنگاری در یک عنصر امن انجام می‌شود و میزبان از طریق I2C درخواست می‌فرستد. در پیکربندی مناسب، کلید خصوصی درون تراشه می‌ماند و میزبان نتیجه عملیات را می‌گیرد. برای طراح امنیت تعبیه‌شده، پرسش اصلی این است که چه کسی حق درخواست کدام عملیات را دارد و طرف مقابل چگونه نتیجه آن را تأیید می‌کند.
فرض کنید چند حسگر قرار است به یک سرویس ثبت داده متصل شوند. می‌توانید برای هر واحد هویت مستقلی تعریف کنید تا از دست رفتن یک دستگاه، همه حسگرها را به یک اندازه تحت تأثیر قرار ندهد. برد آزمایش به شما اجازه می‌دهد ثبت هویت، پاسخ به چالش، تعویض یک واحد و لغو اعتماد به آن را جداگانه تمرین کنید. در این طراحی، شماره سریال یک دستگاه اطلاعات شناسایی است. داشتن شماره یا چاپ آن روی برچسب، به تنهایی برای اثبات داشتن کلید خصوصی کافی نیست.
نقشه اعتماد را پیش از سیم‌کشی بکشید
دستگاه، میزبان محلی، سرور ثبت و مرجع تصمیم چهار نقش متفاوت دارند. دستگاه ممکن است کلید بسازد یا عملیات انجام دهد، ولی فهرست کلیدهای مورد اعتماد معمولاً در طرف تأییدکننده قرار دارد. مشخص کنید چه فرایندی کلید عمومی یک واحد را به نام و مجوز آن وصل می‌کند. اگر هر کلید تازه‌ای بدون کنترل به فهرست اضافه شود، کیفیت حفاظت کلید خصوصی مشکل ثبت بی‌ضابطه را حل نمی‌کند. خروجی تمرین نخست بهتر است یک نقشه ساده از مسیر ثبت و استفاده باشد، همراه با مسئول هر مرحله.
همچنین روشن کنید که دستگاه قرار است چه ادعایی را ثابت کند. امضای یک چالش می‌تواند دسترسی به کلید را نشان دهد، ولی به تنهایی سالم بودن برنامه میزبان یا درست بودن اندازه‌گیری حسگر را ثابت نمی‌کند. اگر میزبان آلوده بتواند هر پیامی را برای امضا به تراشه بدهد، محدوده اعتماد فراتر از نگهداری کلید خواهد بود. طراحی کاربرد باید درخواست‌ها، قالب داده و شرایط استفاده را محدود کند. این تفکیک در گزارش آزمایش مانع تعمیم نتیجه «کلید از مسیر معمول خوانده نمی‌شود» به ادعاهای وسیع‌تر می‌شود.
مشخصات نمونه واقعی
برگه محصول از قابلیت‌هایی مانند توافق کلید، AES با کلید ۱۲۸ بیتی، تولید اعداد تصادفی و عملیات مرتبط با SHA-256 و HMAC نام می‌برد. قابل استفاده بودن هر قابلیت به نوع تراشه، پیکربندی، سیاست خانه‌های ذخیره و پشتیبانی کتابخانه بستگی دارد. برای نمونه‌ای که به دست شما رسیده نوشته روی تراشه، شماره محصول برد و اطلاعات نسخه را ثبت کنید. اسناد خانواده مشابه برای آشنایی مفیدند، اما جای مستندات همان قطعه و پیش‌نیازهای پیکربندی آن را نمی‌گیرند.
نسخه تراشه و وضعیت اولیه نمونه اهمیت عملی دارد. یک قطعه ممکن است از پیش برای کاربردی مشخص پیکربندی شده باشد و آزادی انتخاب خانه‌ها یا الگوریتم‌ها محدودتر از انتظار باشد. قبل از اجرای مثال کتابخانه بررسی کنید آیا مثال فقط اطلاعات می‌خواند یا بخشی از حافظه پیکربندی را قفل می‌کند. نام‌هایی مانند «راه‌اندازی سریع» درباره برگشت‌پذیری فرمان‌ها چیزی نمی‌گویند. یک نمونه آموزشی جدا در نظر بگیرید و هیچ راز تولیدی را صرفاً برای اثبات کار کردن سیم‌کشی روی آن قرار ندهید.
آزمون ارتباط بدون تغییر ماندگار
برد از I2C استفاده می‌کند و کانکتور سازگار می‌تواند سیم‌بندی را آسان‌تر کند. ولتاژ تغذیه و منطق را از راهنمای همان برد و میزبان تطبیق دهید. ابتدا با یک باس کوتاه، زمین مشترک و تنها یک وسیله شروع کنید. دیدن پاسخ در پیمایش آدرس نشانه‌ای از حضور یک وسیله است، نه اثبات هویت درست آن. با ابزار رسمی یا کتابخانه سازگار اطلاعات مجاز مانند نسخه یا شناسه نمونه را بخوانید و نتیجه را با پرونده دستگاه تطبیق دهید.
اگر تراشه پاسخ نمی‌دهد، شیوه بیدار کردن قطعه و زمان‌بندی کتابخانه را نیز بررسی کنید. یک پیمایش ساده باس الزاماً همه رفتارهای لازم برای ارتباط با عنصر امن را انجام نمی‌دهد. از نمونه مستند همان کتابخانه آغاز کنید و نسخه نرم‌افزار، نوع میزبان و نتیجه هر فراخوانی را نگه دارید. خطای انتقال را از خطای وضعیت عملیات جدا ثبت کنید. بازگرداندن یک کد ناموفق از تراشه نشان می‌دهد ارتباط تا مرحله‌ای پیش رفته است؛ این با نرسیدن هیچ پاسخ الکتریکی تفاوت دارد.
شناخت خانه‌ها و اثر قفل کردن
در این خانواده، پیکربندی تعیین می‌کند خانه‌های ذخیره چه کاربردی دارند، چه عملیاتی مجاز است و داده تحت چه شرایطی قابل استفاده خواهد بود. قفل کردن بخش‌هایی از پیکربندی می‌تواند تصمیمی دائمی باشد. پیش از این مرحله، برای هر خانه هدف، نوع کلید، مسیر ساخت یا ورود، مجوز عملیات و روش جایگزینی قطعه را بنویسید. اگر برای یک خانه پاسخ روشنی ندارید، اجرای یک مثال عمومی که همه خانه‌ها را با طرح پیش‌فرض قفل می‌کند ممکن است انتخاب مناسبی برای نمونه شما نباشد.
برای تمرین، نقشه پیشنهادی را ابتدا خارج از سخت‌افزار بازبینی کنید. یک خانه برای کلید هویت دستگاه در نظر بگیرید و روشن کنید کلید عمومی چگونه استخراج و ثبت می‌شود. اگر طرح از کلید متقارن استفاده می‌کند، مسئول نگهداری نسخه طرف سرور و فرایند بازیابی را مشخص کنید. یک راز مشترک بین همه واحدها دامنه اثر افشا را افزایش می‌دهد. در پرونده آزمون، وضعیت قفل را پیش و پس از عملیات بخوانید و نتیجه را خارج از دستگاه نگه دارید تا خطای تولید قابل پیگیری باشد.
نمونه چالش و پاسخ
در یک آزمایش ساده، تأییدکننده برای هر نشست یک چالش تازه و غیرقابل پیش‌بینی می‌سازد. میزبان داده‌ای با قالب تعریف‌شده به عنصر امن می‌دهد و پاسخ مناسب را دریافت می‌کند. سرور با کلید عمومی ثبت‌شده یا سازوکار متناظر طرح، پاسخ را بررسی می‌کند. دقیقاً مشخص کنید کدام بایت‌ها وارد عملیات می‌شوند. اختلاف در ترتیب فیلدها، کدگذاری متن یا تبدیل عدد می‌تواند پاسخ نامعتبر بسازد حتی وقتی کلید درست است. یک نمونه ثابت از ورودی و روش سریال‌سازی برای اشکال‌زدایی نگه دارید.
حالا چند آزمون منفی اجرا کنید. پاسخ نشست قبلی را برای چالش تازه عرضه کنید، یک بایت از پیام را تغییر دهید و پاسخ دستگاه دیگری را برای شناسه اول بفرستید. هر سه باید در منطق تأییدکننده رد شوند. اگر یک پاسخ قدیمی پذیرفته می‌شود، مشکل ممکن است از مدیریت چالش و عمر نشست باشد، نه از عملیات رمزنگاری تراشه. زمان انقضا، مصرف یک‌باره و اتصال پاسخ به هویت و کاربرد مورد نظر در سطح پروتکل مشخص می‌شوند و باید در آزمایش جداگانه بررسی شوند.
ثبت اولیه و جلوگیری از تعویض هویت
در کارخانه یا آزمایشگاه، یک مسیر کنترل‌شده برای ثبت نخستین کلید لازم است. پیشنهاد عملی این است که هنگام ثبت، شناسه فیزیکی واحد، کلید عمومی و نتیجه یک آزمون زنده را با یک رکورد واحد پیوند دهید. سپس کلید ثبت‌شده باید از مسیر مدیریت معتبر به تأییدکننده برسد. اگر مهاجم بتواند رکورد عمومی را با کلید خودش جایگزین کند، دستگاه واقعی همچنان کلید خصوصی خود را حفظ کرده ولی سرویس به شخص دیگری اعتماد خواهد کرد. حفاظت مسیر عمومی ثبت به اندازه حفاظت خود کلید در نتیجه نهایی اثر دارد.
یک خطای معمول آزمایش، جابه‌جایی دو برد مشابه است. برای پیشگیری، شناسه‌ای روی بسته یا میز کار بگذارید و پس از ثبت، آزمایش تعویض فیزیکی انجام دهید. وقتی دو برد را جابه‌جا می‌کنید، سامانه باید تفاوت هویت را درست گزارش کند. از نام پورت USB یا ترتیب اتصال به عنوان هویت پایدار استفاده نکنید. همچنین رکورد دستگاه لغوشده را صرفاً برای خالی کردن فهرست حذف نکنید؛ نگهداری وضعیت لغو و زمان آن برای تحلیل بعدی مفید است.
خرابی، بازیابی و تعویض واحد
اگر کلید خصوصی عمداً غیرقابل خروج طراحی شود، خرابی سخت‌افزار می‌تواند به معنی از دست رفتن همان هویت باشد. برنامه عملیاتی باید امکان ثبت هویت تازه، لغو هویت قبلی و پیوند شفاف آن با دارایی یا کاربر را پیش‌بینی کند. پشتیبان گرفتن از پایگاه کلیدهای عمومی این نیاز را حذف نمی‌کند، اما به بازسازی فهرست اعتماد کمک می‌کند. در تمرین آزمایشگاهی، یک واحد را از دسترس خارج کنید و ببینید تیم چگونه دستگاه جایگزین را بدون پذیرفتن همزمان هویت قدیمی فعال می‌کند.
همچنین قطع برق یا ارتباط در میانه فرایند ثبت می‌تواند رکورد نیمه‌کامل ایجاد کند. مراحل را طوری طراحی کنید که حالت «دیده شده»، «آماده ثبت» و «تأییدشده» قابل تشخیص باشد. تلاش مجدد نباید بی‌هوا کلید تازه‌ای بسازد، رکورد موجود را بازنویسی کند یا دستگاهی را با پیکربندی نامعلوم فعال تلقی کند. برای هر مرحله یک پرسش قابل خواندن درباره وضعیت واقعی سخت‌افزار تعریف کنید. نتیجه موفق را زمانی ثبت کنید که هم عملیات دستگاه و هم تغییر وضعیت سمت تأییدکننده به پایان رسیده باشد.
تشخیص سه خانواده خطا
وقتی پاسخ تأیید نمی‌شود، نخست قالب پیام و کلید عمومی ثبت‌شده را مقایسه کنید. سپس وضعیت خانه انتخابی و مجوز عملیات را بخوانید و در پایان سراغ زمان‌بندی باس و تغذیه بروید، البته اگر دریافت پاسخ سالم از تراشه تأیید شده است. برای هر لایه یک نمونه مستقل داشته باشید. یک جفت ورودی و خروجی آزمایشی شناخته‌شده، اختلاف کدگذاری را سریع‌تر از تعویض تصادفی کتابخانه آشکار می‌کند. گزارش باید نشان دهد کدام مرحله شکست خورده، بدون آنکه رازها یا محتوای حساس در لاگ عمومی ثبت شود.
معیار پذیرش این میز فقط تولید یک امضا نیست. یک دستگاه ثبت‌شده باید برای چالش تازه موفق باشد، دستگاه ناشناخته و پاسخ قدیمی رد شوند، تغییر پیام تشخیص داده شود و دستگاه لغوشده نتواند دوباره با رکورد قدیمی فعال شود. در کنار نتایج، مدل برد، نسخه کتابخانه و وضعیت پیکربندی را نگه دارید. چنین پرونده‌ای نشان می‌دهد عنصر امن در کدام بخش از سامانه نقش دارد و چه تصمیم‌هایی همچنان در برنامه میزبان و سرویس ثبت اجرا می‌شوند.
