معرفی پروتکل DLMS

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

از آنجایی که اندازه‌گیری هوشمند و به طور کلی، دستگاه‌های هوشمند به یک زبان استاندارد پذیرفته شده جهانی نیاز دارند که قابلیت همکاری، کارایی و امنیت را تضمین کند، برای دستیابی به این اهداف، پروتکل DLMS/COSEM که دارای سرویس‌هایی برای ارتباط با تجهیزات اندازه‌گیری انرژی مانند برق، آب، گاز یا گرما می‌باشد ایجاد گردید. سهولت یکپارچه‌سازی سیستم، قابلیت همکاری و امنیت داده‌ها هدف اصلی استاندارد DLMS/COSEM است.

البته پروتکل‌های ارتباطی زیادی وجود دارند که مشابه DLMS برای برآورده کردن نیازهای مختلف توسعه یافته‌اند اما هیچ کدام از آنها جامعیت کافی برای کنترل و مدیریت هوشمند انرژی را ندارند. برخی از پروتکل های ارتباطی رایج که توسط استانداردهای مختلف تعریف شده و در صنعت و کاربردهای اندازه‌گیری هوشمند مورد استفاده قرار می‌گیرند عبارتند از:

Modbus, Profibus, CANBus, IEC 62056-21 (Mod C), DNP3, IEC 870-5-101/102/103, IEC 61850

برخی از برتری‌های استاندارد DLMS نسبت به سایر استانداردهای ارتباطی عبارتند از:

• این استاندارد به کاربران کمک می‌کند تا با استفاده از درایورهای عمومی، امکان برقراری ارتباط با انواع مختلف کنتور از سازندگان مختلف را داشته باشند.
• این استاندارد یک لایه مستقل از پروفایل ارتباطی، برای ارسال و دریافت درخواست‌ها در لایه کاربردی ایجاد می‌کند. این ویژگی، لایه کاربردی را قادر می‌سازد تا پروفایل‌های ارتباطی مختلفی از جمله IPv4، TCP/IP، HDLC و غیره را پشتیبانی کند و مستقل از رسانه ارتباطی باشد.
• DLMS/COSEM را می‌توان برای همه ابزارها، انواع انرژی، تمام بخش‌های بازار، همه برنامه‌ها و تقریباً بر روی هر رسانه ارتباطی استفاده کرد.
• DLMS/COSEM یک مدل رابط را تعریف می‌کند که برای انواع انرژی مانند برق، گاز، آب، گرما و غیره معتبر است.
• پشتیبانی، رمزگذاری داده‌ها و احراز هویت چهار مرحله ای با استفاده از الگوریتم رمزنگاری و کلیدهای رمزنگاری مخفی، امنیت این پروتکل را تضمین می‌کند.
• برخی از عملکردهای پرکاربرد کنتور از قبیل برنامه‌ریزی تعرفه، مدیریت بار، کیفیت توان، همگام‌سازی تاریخ و ساعت و غیره، بصورت کاملا استاندارد تعریف شده است.

الزامات پروتکل ارتباطی:

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

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

پروتکل DLMS/COSEM از الگوی سرور (Server) و کلاینت (Client) استفاده می‌کند که در آن دستگاه‌های انتهایی (کنتورها) “سرور” و Head End Systems (سرورهای مرکزی)، “کلاینت” هستند.

بررسی امنیت در لایه کاربردی پروتکل:

سرویس‌های لایه کاربردی پروتکل عبارتند از:

• ACSE  که شامل سرویس‌هایی برای بازکردن و بستن اتصال بین کلاینت و سرور است.
• xDLMS که شامل سرویس‌هایی برای تبادل اطلاعات بین کلاینت و سرور می‌باشد.

شناسایی و احراز هویت (ACSE):

• مکانیسم شناسایی: این ویژگی، به سرور(کنتور) اجازه می‌دهد که بین کاربران مختلف در سمت کلاینت، تمایز قائل شود و فعالیت آنها را حین دسترسی به کنتور، ثبت نماید. کنتورهای طرح فهام دارای چهار سطح دسترسی Public، Reading ، Management و Pre-stablished می‌باشند.
• مکانیسم های احراز هویت: دارای سه سطح امنیتی Lowest Level Security، Low Level Security(LLS) و High Level Security(HLS)

در سطح امنیتی Lowest level security(None) هیچ شناسایی از سمت سرور و کلاینت انجام نمی‌شود. هدف از احراز هویت بدون امنیت این است که به کلاینت اجازه دهد برخی اطلاعات اولیه دستگاه مانند نام منطقی یا شماره سریال دستگاه را قرائت نماید.

در سطحLow Level Security (LLS)، احراز هویت کلاینت با استفاده از تأیید رمز عبور انجام می‌شود و هنگامی استفاده می‌شود که کانال ارتباطی امنیت کافی را برای جلوگیری از شنود (eavesdroppers) و پاسخ پیام (رمز عبور) (message replay) فراهم کند. مطابق با الزامات طرح فهام، دسترسی به این سطح امنیتی در کارخانه بسته می‌شود و فقط برای انجام تست در آزمایشگاه استفاده می‌شود.

در سطح امنیتی High Level Security (HLS)، هم برای کلاینت و هم برای سرور، احراز هویت انجام می‌شود. احراز هویت در اینجا یک فرایند چهار مرحله ای می‌باشد. احراز هویت امنیت سطح بالا معمولا هنگامی مورد استفاده قرار می‌گیرد که کانال ارتباطی هیچ امنیت ذاتی را ارائه نمی‌دهد و اقدامات احتیاطی باید در برابر شنود (eavesdroppers) و پاسخ پیام (رمز عبور) (message replay) انجام شود.

معرفی تابع GCM(Galois/Counter Mode):

• GCM بر اساس یک بلوک رمزگذاری مبتنی بر کلید متقارن (symmetric key block cipher) با اندازه بلوک های 128 بیتی ساخته می‌شود. بنابراین می‌توان گفت این تابع یکی از مدهای الگوریتم رمزنگاری AES است.
• در DLMS/COSEM از این الگوریتم برای رمزنگاری اطلاعات محرمانه استفاده می‌شود. همچنین یک تگ احراز هویت نیز روی داده‌های محرمانه و هر داده غیرمحرمانه اضافی نیز محاسبه می‌شود. تابع رمزگشایی، مشروط به تایید تگ، داده‌های محرمانه را رمزگشایی می‌کند. بنابراین می‌توان گفت که GCM، یک الگوریتم رمزنگاری احراز هویت شده است.
• چنانچه ورودی به داده‌های غیرمحرمانه محدود شود، مقدار حاصل از GCM را GMAC می‌نامند. در این حالت GCM به تابعی برای محاسبه و تایید تگ احراز هویت تبدیل می‌شود.

پارامترهای الگوریتم AES-GCM در مد رمزنگاری:

• EK: کلید رمزنگاری بلوک‌ها با طول 128 بیت( 16 بایت)
• P: اطلاعات محرمانه که باید رمزنگاری شود.
• A: داده‌های اضافی جهت ایجاد تگ احراز هویت که به آن AAD(Additional Authentication Data) می گوییم. در DLMS این مقدار شامل دو پارامتر AK و SC می‌باشد.
• IV: در DLMS/COSEM این مقدار شامل دو بخش است. یک بخش ثابت 8 بایتی که بیانگر مشخصه فیزیکی دستگاه است (Sys-T) و بخش دوم که شامل یک شمارنده 4 بایتی می‌شود(IC). تابع GCM با استفاده از تغییر مقدار شمارنده، محرمانه بودن داده های رمزنگاری شده را فراهم می‌کند.
• C: متن رمز شده. طول C با P برابر است.
• T: تگ احراز هویت. در پروتکل DLMS طول این مشخصه 96 بیت(12 بایت) باید باشد.

نکته: P و AAD دو گروه داده هستند که GCM از آنها محافظت می‌کند.

پارامترهای الگوریتم AES-GCM در مد رمزگشایی:

• P: اطلاعات محرمانه که با رمزگشایی Cipher text بدست آمده است
• Fail: چنانچه در اعتبارسنجی تگ ورودی خطایی رخ دهد.

دسته‌بندی کلیدها در فهام:

• Global Authentication key(GAK): در کلاینت Management به عنوان بخشی از پارامتر ADD در الگوریتم AES-GCM برای تولید کد احراز اصالت پیام، استفاده می‌شود. این کلید بطور مستقل و یکتا در هر کنتور و متناظراً در AHE وجود دارد.
• Global Broadcast Encryption key(GBEK): در کلاینت Pre-Stablished به عنوان کلید EK در الگوریتم AES-GCM استفاده می‌شود. این کلید بطور مشترک در تمامی کنتورها و متناظراً در AHE وجود دارد.
• Global Unicast Encryption key(GUEK): در کلاینت Management به عنوان کلید EK در الگوریتم AES-GCM استفاده می‌شود. این کلید بطور مستقل و یکتا فقط در هر کنتور و متناظراً در AHE وجود دارد. 
• Global Reading Authentication key: در کلاینت Reading به عنوان کلید AK در الگوریتم AES-GCM استفاده می‌شود.
• Global Reading Encryption key: در کلاینت Reading به عنوان کلید EK در الگوریتم AES-GCM استفاده می‌شود.          
• Master key(KEK): در فرایند تغییر کلید، به عنوان کلید ورودی الگوریتم RFC3394 برای Wrap کردن کلید جدید، به کار می‌رود.
• Dedicated Key: این کلید در پروسه باز کردن نشست (ACSE) توسط کلاینت (AHE) ایجاد و برای سرور (کنتور) ارسال می‌شود. این کلید جایگزین EK در پروسه تبادل اطلاعات (xDLMS) می‌شود و تا انتهای همان نشست معتبر خواهد بود.
• HLS Secret Key: این کلید در مکانیسم احراز هویت MD5 و SHA-1 استفاده می‌شود. این دو مکانیسم از اسناد فهام حذف شده اند و استفاده نمی‌شوند.

رمزنگاری در سرویس‌های ACSE و xDLMS APDU:

• به ابتدای پیام رمز شده، یک تگ بر اساس لیست زیر اضافه می‌شود.

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

مثال برای ساخت glo-get-request xDLMS APDU:

معرفی توابع هش در استاندارد DLMS:

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

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

در استاندارد DLMS سه تابع هش MD5، SHA-1 و GMAC معرفی شده است. البته در ورژن جدید DLMS توصیه شده که از مکانیسم‌های MD5 و SHA-1 استفاده نشود لذا استفاده از این دو مکانیسم از اسناد طرح فهام حذف گردید و فقط مکانیسم GMAC مورد استفاده است.

همانطور که اشاره کردیم، مکانیسم احراز هویت در سطح امنیتی HLS، دارای چهار مرحله است که این چهار مرحله در شکل زیر نمایش داده شده است:

Note: C(Client), S(Server), CtoS(Challenge client to server), StoC(Challenge server to client)

مثال برای مکانیسم احراز هویت HLS با استفاده از تابع GMAC:

هنگام ساخت GMAC ، ADD= 10 +AK+StoC است. در این حالت P را خالی میگذاریم. تگ تولید شده در این حالت همان GMAC است

برای تولید تابع هش GMAC باید در الگوریتم AES-GCM، مقدار SC برابر با 10 باشد، زیرا فقط authentication داریم. لذا برابر با ADD= 10 +AK+StoC خواهد بود. همچنین در این حالت مقدار P را خالی می‌گذاریم. تگ تولید شده در این حالت همان GMAC خواهد بود.

بررسی امنیت در پروسه بروزرسانی:

بروزرسانی دستگاه‌های DLMS از نظر امنیتی شامل سه مرحله اصلی زیر هستند:

• محاسبه و تولید پارامتر Image Id
• ارسال پارامتر Image Id برای دستگاه با استفاده از متد image_transfer_initiate
• در صورت تایید مرحله قبل توسط دستگاه، فایل آپدیت (که می تواند رمزنگاری شده باشد) برای دستگاه ارسال می شود.

مراحل ساخت Image Id:

قبل از اینکه مراحل ساخت Image Id را توضیح دهیم لازم است که الگوریتم امضای دیجیتال Elliptic Curve Digital Signature (ECDSA) را که در فرایند تولید Image Id از آن استفاده می‌شود را توضیح دهیم:

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

حال می توانیم سراغ مراحل ساخت Image Id برویم:

از یک تابع هش در فرآیند تولید امضا برای به دست آوردن یک نسخه فشرده از داده‌هایی که باید امضا شوند استفاده می‌شود که خلاصه پیام (Message digest) یا مقدار هش (Hash Value) نامیده می‌شود. سپس خلاصه پیام برای تولید امضای دیجیتال به الگوریتم امضای دیجیتال وارد می‌شود. امضای دیجیتال همراه با داده‌های امضا شده (که اغلب پیام نامیده می‌شود) به تأییدکننده مورد نظر ارسال می‌شود. تأیید کننده پیام و امضا با استفاده از کلید عمومی امضاکننده، امضا را تأیید می‌کند.

• تولید Image identifier و بخش‌های تشکیل دهنده آن یک پروسه اختصاصی و مربوط به سازنده می‌باشد. در دستگاه های تولید شرکت بهینه‌سازان‌توس، این پارامتر از دو قسمت تشکیل می‌شود. قسمت اول شامل یک سری اطلاعات عمومی از جمله مشخصه شرکت، مدل دستگاه، ورژن نرم‌افزار و… است. قسمت دوم که توسط الگوریتم AES-GCM-128  رمز می‌شود، از دو بخش امضای دیجیتال فایل آپدیت و شمارنده ورژن نرم‌افزار تشکیل شده است.
• کاربرد شمارنده ورژن نرم‌افزار، جلوگیری از آپدیت دستگاه به ورژن فعلی و یا ورژن‌های قبلی می‌باشد.

مثال برای ساخت Image Id:

بررسی امنیت در پروسه تعویض کلید:

برای بسته‌بندی کلیدها حین تعویض کلید، DLMS/COSEM الگوریتم بسته‌بندی کلید AES بیان شده در استاندارد RFC 3394 را انتخاب کرده است. این الگوریتم برای بسته‌بندی یا رمزگذاری داده‌های کلیدی طراحی شده است و بر روی بلوک های 64 بیتی کار می‌کند. قبل از بسته‌بندی، داده های کلیدی به n بلوک 64 بیتی تجزیه می‌شوند.

در DLMS از Master Key بعنوان کلید رمزنگاری کلید (Key Encrypting Key) استفاده می‌شود. سایز این کلید 16 بایت است. کلید جدید توسط کلاینت تولید و با استفاده از master key ،wrap می‌شود. سپس با استفاده از متد key_transfer در آبجکت security setup، برای سرور ارسال می‌شود. لذا کلیدها علاوه بر wrap شدن، بصورت رمزنگاری شده نیز برای کنتور ارسال می‌شود. سرور با داشتن کلید master key می‌تواند کلید جدید را unwrap کند.

Wrap کردن کلید با بحث رمزنگاری تفاوت دارد، زیرا فرایند wrap کردن موجب حفظ یکپارچگی دیتا می‌شود. لذا در طول فرایند unwarp کردن دیتا، تغییرات عمدی یا تصادفی در دیتا قابل تشخیص است.

نویسنده: مجتبی سعیدی