STIR/SHAKEN چیست و چه اجزایی دارد؟

در سال‌های اخیر، با افزایش تصاعدی تماس‌های خودکار (robocalls) و جعل شناسه تماس‌گیرنده نه تنها این موضوع باعث ایجاد مزاحمت برای کاربران شده است، بلکه نگرانی‌های امنیتی و حریم خصوصی قابل‌توجهی را نیز برانگیخته است. در پاسخ به این مسئله، چارچوبی با نام STIR/SHAKEN معرفی شده است که هدف آن مبارزه با چنین شیوه های فریبنده و احراز هویت تماس گیرنده می‌باشد.

در این مقاله قصد داریم تا به توضیح STIR/SHAKEN چیست بپردازیم و اجزای آن را نیز مورد بررسی قرار دهیم.  

STIR/SHAKEN چیست؟

STIR (مخفف Secure Telephone Identity Revisited) و SHAKEN (مخفف Signature-based Handling of Asserted information using toKENs) پروتکل‌هایی هستند که برای اطمینان از صحت شناسه تماس گیرنده و جلوگیری از جعل هویت او طراحی شده‌اند. این دو نام اختصاری اغلب به همراه یکدیگر مورد استفاده قرار می‌گیرند زیرا STIR چارچوب فنی را ارائه می‌کند، در حالی که SHAKEN نحوه پیاده‌سازی و استفاده از این چارچوب را شرح می‌دهد.

تصویر زیر، نشان‌دهنده نحوه عملکرد STIR/SHAKEN می‌باشد.

اجزای STIR/SHAKEN

STI-AS (سرور STI-Authentication)

REST API را برای امضای درخواست‌ها ارائه می‌کند و برای انجام این کار به کلیدهای خصوصی در SKS دسترسی دارد.

STI-VS (سرور STI-Verification)

REST API را برای درخواست‌های تایید ارائه می‌کند و کلیدهای عمومی را از طریق اینترنت و با استفاده از URL موجود در درخواست بازیابی می‌کند.

Authenticator 

REST API که توسط STI-AS و STI-VS ارائه می‌شود، در ATIS 1000082 نیز می‌بایست تعریف شده باشد تا بتوان آن‌را توسط یک Authenticator فراخوانی نمود. Authenticator جزء شبکه carrier یا ارائه دهنده خدمات محسوب می‌شود و سرویس احراز هویت و امضا را برای ایجاد و تأیید امضاهای دیجیتال فراخوانی می‌کند. Authenticator در شبکه IMS می‌تواند I-BCF باشد، یا در یک شبکه‌های غیر IMS می‌تواند SBC یا سافت سوئیچ NGN نیز باشد. همچنین می‌توان Authenticator را به عنوان بخشی از سرور اپلیکیشن SIP در نظر گرفت که سرویس STIR/SHAKEN را ارائه می‌دهد.

SKS (Secure Key Store)

کلیدهای خصوصی در SKS برای استفاده توسط STI-AS در امضای درخواست ها ارائه شده است. هر کلید خصوصی باید بسیار ایمن نگه داشته شود، زیرا این یک راز است که فقط شرکت مخابراتی که تماس را امضا می کند، می شناسد.

کلیدهای خصوصی که توسط SKS ارائه می‌شوند، توسط STI-AS جهت امضای درخواست‌ها مورد استفاده قرار می‌گیرند. در نظر داشته باشید که از هر کلید خصوصی باید بصورت کاملاً ایمن نگهداری شود.

STI-CR (Certificate Repository)

یک وب سرور HTTPS است که مسئول هاستینگ گواهینامه های عمومی بوده و برای سایر ارائه دهندگان خدمات از طریق اینترنت قابل دسترسی است. هر ارائه‌دهنده خدمات با کلیدهای خصوصی SHAKEN در یک SKS باید یک STI-CR مربوطه داشته باشد تا گواهی‌های عمومی امکان انتشار داشته باشند.

SP-KMS (سرور مدیریت کلید)

گواهی خودکار و مدیریت کلید را ارائه می دهد. SP-KMS درخواست توکن را از STI-PA و از طریق اینترفیس HTTP ارسال می کند همچنین SP-KMS از STI-CA یک گواهی STI درخواست می کند و یک جفت کلید خصوصی و عمومی برای امضا و تأیید تولید می کند و آنها را به ترتیب در SKS و STI-CR ذخیره می‌نماید.

 

سطوح تصدیق امضاء

هنگامی که STI-AS امضای دیجیتال را ایجاد می کند، به carrier این امکان را می‌دهد تا از بابت عدم جعل شناسه تماس گیرنده اطمینان حاصل کند. برای دستیابی به سطح اطمینان از سطح گواهی استفاده می‌شود که به ترتیب Full (A)، Partial (B) و Gateway (C) خواهند بود.

Full (A)

گواهی فول بدین معناست که carrier تماس را امضا می‌کند و:

• مسئول برقراری تماس بر روی شبکه صوتی مبتنی بر IP است.

• با مشتری تماس برقرار می‌کند و می تواند مشتری را شناسایی کند.

• یک ارتباط مورد تایید با شماره تلفن مورد استفاده برای تماس برقرار کرده است.

به عبارت دیگر، شرکت مخابراتی (carrier) از این طریق خواهد فهمید که شناسه تماس گیرنده جعل نشده است.

Partial (B) 

این گواهی یعنی شرکت مخابراتی تماس را امضا می کند و:

• مسئول برقراری تماس با شبکه صوتی مبتنی بر IP خود است.

• با کاربر تماس برقرار می‌کند و می‌تواند کاربر را شناسایی کند.

• نمی‌تواند یک ارتباط مورد تایید با شماره تلفن مورد استفاده برای تماس برقرار کند.

به عبارت دیگر، اگرچه شرکت مخابراتی مبدأ تماس بوده و با کاربر برقرار کننده تماس ارتباط دارد، اما نمی‌توان از بابت اینکه شناسه تماس گیرنده جعل نشده باشد، مطمئن بود.

Gateway (C)

این گواهی نیز این معنا و مفهوم را می‌رساند که شرکت مخابراتی تماس را امضا می‌کند و:

نقطه ورود تماس به شبکه VoIP اپراتور است.

هیچ رابطه‌ای با آغازگر تماس ندارد (مانند گیت‌وی‌های بین‌المللی).

به عبارت دیگر، شرکت مخابراتی به هیچ وجه نمی تواند شناسه تماس گیرنده را تضمین کند و فقط می تواند به طور مشخص بگوید که تماس از کجا وارد شبکه شده است. هدف اصلی گواهینامه Gateway صرفاً ردیابی تماس است.

مانند پایان دادن به تماسی که در حال وارد شدن به شبکه بر روی ترانک های TDM و گیت وی TDM-IP می‌باشد.

 

نمونه امضا و تأیید

معماری استقرار رایج برای SHAKEN این است که:

• تماس ها هنگام خروج از شبکه اپراتور مبدا توسط Interconnect SBC امضا می شوند و به STI-AS می‌روند.

• تماس‌ها با ورود به شبکه carrier، توسط Interconnect SBC که با STI-VS تماس می‌گیرد تأیید می‌شوند.

در ادامه، به مثالی از این معماری اشاره خواهیم نمود.

 

امضا

امضا از چهار مرحله مجزا تشکیل شده است.

مرحله 1. درخواست امضای ورودی از طریق SHAKEN API

Interconnect SBC در carrier مبدأ یک تماس از طریق SIP دریافت می کند و برای احراز هویت شناسه تماس گیرنده آن را به STI-AS ارسال می‌کند. در تصویر زیر نمونه ای از یک درخواست امضا شده وجود دارد که از طریق SHAKEN RESTful API این کار انجام شده است.

اجزای مهم این درخواست به شرح زیر می‌باشد:

مبدا DN (orig). این شماره تلفن شخصی است که تماس می‌گیرد.

مقصد DN (dest). این شماره تلفن شخصی است که با او تماس گرفته می‌شود.

زمان آغاز شدن (iat). زمانی که درخواست شروع می‌شود.

شناسه مبدا (origid). این یک شناسه منحصربه‌فرد جهانی است که نقطه مبدا تماس را نشان می‌دهد. این اطلاعات برای کمک به ردیابی منشا تماس در شبکه مورد استفاده قرار می‌گیرد.

سطح تصدیق (attest). بیانگر سطح تأیید تماس (Full، Partial یا Gateway) می‌باشد.

مرحله 2. STI-AS امضا را ایجاد می کند

پس از دریافت درخواست امضا، STI-AS یک هدر Identity ایجاد می کند که اغلب به عنوان PASSport یا امضای دیجیتال نیز نامیده می شود. این هدر با کد base64 است و می تواند به فرمت قابل خواندن برای انسان تبدیل گردد.

هدر (به رنگ قرمز) نشان می دهد که این یک STIR/SHAKEN PASSport است که عنصر x5u حاوی URL گواهی عمومی (STI-CR) برای ارائه دهنده خدمات است که تماس را امضا می کند.

پی‌لود یا Payload (به رنگ آبی) حاوی اطلاعات مربوط به امضای درخواست امضای اصلی است.

امضا (به رنگ سبز) به ارائه دهنده خدمات اجازه می دهد تا تماس را به طور ایمن تأیید کند. در واقع این کار را با استفاده از تکنیک‌های رمزنگاری استاندارد انجام می‌دهد که در سطح بالایی شامل ایجاد یک توکن هش‌شده منحصربه‌فرد با استفاده از کلید خصوصی ارائه‌دهنده خدمات و سایر اطلاعات خاص این تماس است. رمز را فقط می توان با استفاده از کلید عمومی ارائه دهنده خدمات تأیید کرد.

مرحله 3. STI-AS به درخواست‌های تحت SHAKEN API پاسخ می دهد

پس از ایجاد امضا، پاسخ از طریق API با هدر (به رنگ قرمز)، Payload (به رنگ آبی) و Signature (به رنگ سبز) به SBC ارسال می شود.

مرحله 4: Identity به پیام SIP اضافه می‌‌شود

در نهایت، هدر Identity به پیام SIP اضافه می‌شود و جریان تماس SIP به صورت عادی خارج از شبکه carrier ادامه می یابد.

تایید (Verification)

تایید شامل سه مرحله است.

مرحله 1: درخواست تأیید ورودی از طریق SHAKEN API

Interconnect SBC در شبکه provider، تماس را با یک امضا در آن دریافت می کند و سپس SBC امضا را از پیام SIP استخراج نموده و یک درخواست تأیید را از طریق SHAKEN API ارسال می کند.

مرحله 2: STI-VS درخواست را تأیید می کند

STI-VS جزئیات مربوطه را از درخواست استخراج می‌کند و گواهی عمومی را از STI-CR ارائه‌دهنده خدمات مبدأ و با استفاده از URL که در هدر اطلاعات وجود دارد، خارج می‌کند. گواهی عمومی ممکن است توسط STI-VS کش شود، اگر STI-VS قبلاً در هنگام پردازش درخواست تأیید قبلی از همان ارائه دهنده خدمات مبدأ، درخواستی برای آن گواهی ارائه کرده باشد. هدف از کش کاهش زمان تأخیر در طول فرآیند تأیید است.

هنگامی که گواهی عمومی بازیابی شد، STI-VS امضای دیجیتال را با استفاده از تکنیک های رمزنگاری استاندارد تأیید می کند. نتیجه تأیید سپس در هدر verstat در پاسخ قرار می گیرد و می تواند مقادیر زیر را بگیرد.

TN-Validation-Passed: تأیید موفقیت آمیز.

TN-Validation-Failed: تأیید ناموفق.

No-TN-Validation: هیچ اعتبارسنجی رخ نداده است.

مرحله 3: STI-VS از طریق SHAKEN API به درخواست پاسخ می دهد

در نهایت، نتیجه تأیید در پاسخی که از طریق API به SBC بازگردانده می‌شود، encapsulate می‌شود. در تصویر زیر، تأیید با موفقیت انجام شده است.

سخن آخر

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

این چارچوب تصدیق تماس توسط ارگان‌های نظامی و کارشناسان فنی برای مقابله با افزایش تماس‌های فریبنده و سوءاستفاده از شماره‌های تلفن طراحی شده‌است. هدف از آن محافظت از عموم مردم در برابر کلاهبرداران و اطمینان از انتقال تماس‌های معتبر است.