امضای دیجیتالی(5)

فصل چهارم

گسترش ايمني SOAP

امضاي ديجيتالي

خلاصه: اين مدرك (سند) به قوانين پردازش و نحوه ورودي هد SOAP براي انتقال اطلاعات امضاي ديجيتالي در داخل يك نامه SOAP 1.1 اختصاص دارد.

وضعيت:

اين سند يك پيشنهاد به كنسرسيوم شكبه گسترده جهاني است. براي ليست كاملي از تمامي‌پيشنهادات شناخته شده لطفا به پيشنهادات شناخته شده،W3C، مراجعه كنيد. اين سند ياداشتي است كه تنها براي بحث توسط W3C، در دسترس قرار گرفته است. اين سند يادداشتي است كه تنها براي بحث توسط W3c در دسترس قرار گرفته است. انتشار اين يادداشت توسط w3c هيچ تاييدي را توسط تيم W3c يا W3C يا هر عضوي از w3C نشان نمي‌دهد. W3C هيچ كنترل ويرايشي برآماده سازي اين يادداشت ندارد. اين سند كاري در حال پيشرفت است و مي‌تواند به روز شود، جايگزين گردد و يا هر  زمان با ديگر سند ها به طور كامل عرضه شود.

ليستي از سندهاي تكنيكي اخير W3C را مي‌توانيد در صفحه گزارشات تكنيكي بيابيد.

جدول محتويات 1) انگيزه:       الف) پيمان ملي       ب) نحوه ورودي و ثبت:       الف) محل اسم    ب) مدخل ثبت امضا      ج) نشانه SOAP- SEC  د) مثال       3) قوانين پردازش  الف) سنل و دخل ثبت امضا     ب) تاييد مدخل ثبت امضا  4) مسئله ايمني   5) منابع

1)            انگيزه: انگيزه براي  اين يادداشت، ارائه روشي استاندارد براي استفاده از نحوه امضاي ديجيتالي XML (امضا – XML براي امضاي پيام هاي SOAP 1.1 مي‌باشد. ما براي اين منظور يك مدخل ثبت SOAP را تعيين مي‌نماييم. ما هچنين، تعريفي از يك محل اسم گسترده براي افزودن مشخصه هاي امنيتي به ثبت (سر دسته ) SOAP ارائه مي‌دهيم. منظور ما از گسترش اين است كه عوامل جديد مي‌تواند به برنامه  اضافه كاري افزوده شود اما عوامل در برنامه كار تغيير تخواهد كرد. قصد ما اين است كه ديگر مشخصه هاي ايمني را مانند امور محرمانه پيام هاي SOAP 1.1  به اين محل اسم با استاندارد هاي مناسب افزوده شود، مثلا رمز گذاري XML موجود، در دسترس مي‌باشد. آنچه ما به طور ويژه به يادداشت ديگري يا گروه كاري ديگر موكول خواهيم كرد تعريف پروتكل (پيماني) تاييد براي، SOAP منظور ما از پيمان، انتظاري براي پردازش توسط گيرنده يك پيام امضا شده، رمز گذاري شده است.

الف پيمان ملي: كلمات كليدي، (بايد ) ، (نبايد)، (ملزم بودن)، (خواستن) (نخواستن)، (پيشنهاد دادن)، (ممكن بودن) و امكان داشتن در اين سند، همانگونه كه در RFC 2119 (KEYWORDS) كلمات كليدي توضيح داده است، تفسير شده است. محل اسم URI  ها در شكل كلي (برخي URI برخي كاربردهاي مربوط يا موضوعات- مربوط) ارائه مي‌دهد كه در RFC 2396 (URI) مشخص شده است. پيشوند هاي محل اسم، ""SOAP- ENV و "DS" استفاده شده در اين مدرك در محل هاي اسامي‌به ترتيب آمده است.

2- نحو ورودي سر دسته دهد، : الف و2 محل اسم: محل اسم XML (XML-NS) URL , كه بايد با انجام اين مشخصات مورد استفاده قرار گيرد. پيشوندهاي SOAP- SEC""، استفاده شده در اين مشخصات با اين URI همراه هستند.

ب-2 ورودي هد (سر دسته) امضاء: ورودي هد (امضاي  (SOAP- SEC، توسط برنامه زير توضيح داده مي‌شود. (برنامه، XML)، (برنامه 2، (XML عامل > امضاي: SOAP-SEC < حاوي يك امضاي ديجيتالي واحد است كه از مشخصات امضاي XML پيروي مي‌نمايد.  (امضا XML)

ج-2 ويژگي SOAP_SEC:id عامل > مرجع : DS < لازم است تا به قسمت امضا شده نامه SOAP اشاره كند. اين امر مي‌تواند از طريق استفاده از شناساننده XML بدست آيد.تقاضا نامه ها مسئول تشخيص اين امر هستند كه كدام ويژگي ها از نوع idd هستند. براي كمك به تقاضا نامه ها براي تشخيص ويژگي هاي نوع ID اين ويژگي با نام ويژگي جهانيid: SOAP-SEC توضيح داده مي‌شود. اين ويژگي ممكن است براي اشاره به قسمت امضاء شده نامه SOAP مورد استفاده قرار گيرد.

د-2 مثال: اينجا مثالي از پيام SOAP با ورودي سر دسته امضا، وجود دارد كه بدنه SOAP امضا شده و در تنيجه امضا امضا <ds: به امضا> <SOAP-SEC اضافه شده است به ياد داشته باشيد كه ويژگي URI در عامل >  مرجع <ds: به عامل <SOAP- ENV SOAP:Body اطلاق مي‌گردد.

قوانيني پردازش:

ورودي هد امضاء براي انجام يك شكايت رسمي‌امضاء با مشخصات امضاي XML (امضا- XML) با يك نامه SOAP به منظور امضا كردن يك يا چند عامل در نامه SOAP مورد استفاده قرار مي‌گيرد. ورودي هد امضاي چند گانه، ممكن است، به يك نامه SOAP تنهامجرد ) با ديگر عوامل امضا شده روي هم قرار گرفته يا منفضل اضافه شود. يك نسخه بعدي از اين مشخصات ممكن است، بيشتر به نحوه امضا منجر شود تا ديگر امضا XML- از طريق، گسترش (ابر نامه- XML) در مدل پر محتوا > امضاي: <SOAP- SEC مجاز نشناخته شود.

مطابق ساختن تقاضانامه هاي SOAP به اين مشخصه ها بايد به اين شرايط زير تخصيص يابد.

1)تقاضا بايد قادر به پردازش امضاي XML همانگونه كه در مشخصات امضاي XML آمده است باشد.(امضا- XML).

2)اگر يك تقاضاي SOAP تطبيق داده شده به يك ورودي هد (سر دسته) > امضاي: <SOAP- SEC در سر دسته SOAP اضافه گردد، ورودي سر دسته بايد يك عامل > امضاي <ds: داشته باشد كه مطابق، مشخصات امضاي-  XML ]امضا –  [XML باشد. تمامي‌عوامل > مرجع <ds: مشتمل در اين امضا بايد به يك منبع در نامه SOAP ضميمه اطلاق شود و يا به منبعي در بسته پيام SOAP ضميمه اطلاق مي‌شود (الحاق- SOAP) در صورتي كه نامه در بسته پيام 1.1 SOAP اوليه باشد. (الحاق- SOAP).

3 )هنگامي‌كه كاربرد (تقاضاي) SOAP تطبيق شده يك پيام SOAP را دريافت مي‌كند، كه حاوي يك يا چند ورودي سر دسته (هد) > امضا:<SOAP-SEC است كه براي هر يك از اين تقاضا بايد گام هاي زير را انجام داد: 1) تصميم بگيريد كه مي‌خواهيد ورودي سر دسته (هد) را پردازش كنيد يا نه (چه به صورت اجباري يا داوطلبانه)

2) اگر اين پردازش صورت گرفت، تقاضا نامه بايد سعي كند كه امضا را با استفاه از مدل پردازش امضاي XML (امضاي –XML ) اثبات كنيد.

به ياد داشته باشيد كه كاناليزه كردن (مشروع كردن) (XML-CL4N) XML از > امضاي :<ds و ديگر منابع امضا شده بايد هر يك از طريق متن خود صورت پذيرد. اين بدين معني است كه در ميان ديگر موارد كه شكل مشروع دارند،] [XML-CL4N از > امضاي <ds: هميشه اظهاريه محل اسم را براي SOAP- SEC,SOAP-ENV به اسم مي‌برند. بقيه اين بخش كاربردهايي را توصيف مي‌كنند كه براي ورودي هد (رهبر) امضا اجرا شده است.

الف-3: نسل ورودي هد سر دسته (رهبر) امضا: يك روش براي ايجاد يك ورودي سر دسته >  امضا<SOAP- SEN: به قرار زير است:

1) مقصد نام SOAP را با پيكره و سر دسته هاي لازم و ضروري مشخص كنيد.

يك الگو از عامل  > امضاي: <ds ايجاد كنيد. الگوهتور مي‌شود كه حاوي محتويات خالي (تهي)

2)            براي عوامل > ارزش امضا: ds <يا  ارزش خلاصه <ds: باشد اما محتويات با ارزش مناسب براي عوامل ماند > روش امضاي: <ds: و > مرجع: <ds براي محاسبه آنها مورد نياز است.

3)            يك ورودي در (سر دسته) جديد > امضاء : <SOAP-SEC ايجاد نماييد والگو را به اين ورودي بيفزاييد.

4)            يك ورودي سر دسته (هد) > امضاي: <SOAP=SEC براي سر دسته AOAP بيفزاييد.

5)            يك مشخصه، بازيگر SOAP را بيفزاييد ومشخصات را در ورودي در صورت لزوم اضافه كنيد.

6)             عوامل، > ارزش امضا: <ds و > ارزش خلاصه < را مطابق نسل اصلي مشخصات امضاي XML  (امضاي XML- ) محسابه كنيد.

فيلتر كردن راه x مي‌تواند براي اختصاصي كردن موارد (مباحث) مورد استفاده قرار گيرد تابه گونه اي كه در مشخصات امضاي- XML توصيف گرديد، امضا گردد (امضا XML) اگر چه، از زماني كه مدل مبادله پيام SOAP باعث كاربردهاي مياني مي‌گردد و نامه را تغيير مي‌دهد (براي مثال باعث حذف وافزودن ورودي هد (سر دسته) مي‌گردد) فيلتر كردن راه x هميشه به موارد مشابه پس از رساندن پيام ختم نخواهد شد. استفاده از فيلتر كردن راه x بايد مورد توجه و دقت قرار گيرد به طوري كه فقدان تاييد مستمر بستگي به چنين تغييري ندارد. تغيير شكل كه در مشخصات امضاي XML- (امضاي XML ) توضيح داده شده است، ممكن است هنگامي‌كه كل نامه امضا مي‌شود شامل ديگر ورودي (سر دسته) مفيد باشد

ب-3: اثبات ورودي سند (هد) امضا: اثبات يك ورودي هد > امضاي: <SOAP-SEC دچار ايراد مي‌شود اگر:

1)  نحوه محتويات ورودي سر دسته با اين مشخصه ها مطابقت نمي‌كند

2) و يا اعتبار امضا مشتمل در ورودي سر دسته مطابق تاييد اصلي از مشخصات امضاي XML دچار مشكل مي‌شود

3) يا دريافت برنامه كاربردي (تقاضا نامه) امضا را به برخي دلايل رد خواهد كرد، براي مثال، امضا توسط يك كليد غير قابل اعتماد ايجاد شده باشد)

اگر اعتبار ورودي سر دسته امضا از بين برود، تقاضا نامه ها ممكن است نقص فرستنده را گزارش دهد. اين امر خارج از حوزه اين مشخصات براي چگونگي كنار آمدن با اين مورد است

4- تمركز امنيت :

اين مشخصات استفاده از امضاي XML را در سر دسته هاي SOAP11 توضيح مي‌دهد. به عنوان يكي از بلوك هاي ساخت پيام هاي SOAP امنيت دهنده، مقصود بر آن است كه در ارتباط با ديگر روش هاي امنيتي مورد استفاده قرار گيرد. نياز است امضاي ديجيتالي در متن ديگر مكانيزم هاي امنيتي مورد درك قرار گيرد. امضاهاي ديجيتالي مطابق IETF RFC 2828(DIGSIG) هستند. مقداري (ارزشي)، كه با الگوريتم رمز گشايي مورد استفاده قرار مي‌گيرد و به گونه اي به موضوع اطلاعات مربوط است كه هر گيرنده اطلاعاتي مي‌تواند از امضا براي تغيير مبناء و منشاء اطلاعات استفاده كند. اطلاعات يا تغيير شكل رمز گشايي شده، يك بخش اطلاعاتي به گيرنده بخش اطلاعات اجازه مي‌دهد كه منبع و منشاء بخش اطلاعات را ثابت كند و از تقلب جلوگيري مي‌نمايد. براي مثال، امضاي ديجيتالي به تنهايي صحيح بودن پيام را ثابت نمي‌كند. شخص مي‌تواند يك پيام امضا شده را ثبت نمايد و با آن مقابله كند. براي جلوگيري از اين نوع حملات، امضاي ديجيتالي بايد با يك وسيله مناسب تر تركيب شود تا از واحد بودن پيام اطمينان حاصل شود، مثلا ثبت زمان، يك راه برا افزودن اين اطلاعات جايگزين كردن يك عامل اضافي است كه فرزند > امضا<  حساب مي‌شود. هنگامي‌كه امضاي ديجيتالي مورد استفاده قرار مي‌گيرد، تا هويت طرف فرستنده تغيير داده شود، فرستنده بايد وضعيت كليد خصوصي را ثابت كند و بهبود بخشد. يك روش براي كسب اين امر استفاه از نوع پاسخ پروتكل است. استفاده كنندگان بايد همچنين، از تمامي‌عوامل امنيتي كه براي استفاده از امضاي ديجيتالي به طور كلي و به خصوصي در امضاي XML رخ مي‌دهد آگاه باشند. براي ايجاد اطمينان بر پايه امضاي ديجيتالي، نكات ديگر از تكنولوژي وجود دارد كه بايد ارتباط با امضا توضيح داده شود. بايد مدل حقيقي سند شناسايي وجود داشته باشد.

بايد راهي (روشي) وجود داشته باشد تا كليد وسند اطمينان نگهداري و ايجاد شود. و بايد روشي وجود داشته باشد تا اثبات كند كه سند شناسايي باطل نشده است.

ادامه دارد...

آیا این پاسخ به شما کمک کرد؟

 پرینت این مقاله

در همین زمینه

تاریخچه امنیت اطلاعات

براي اینکه نگاهی به تاریخچه امنیت اطلاعات داشته باشیم بد نیست به دوره ظهور یکی از نخستین ماشین...

رویکردی عملی به امنیت شبکه لایه بندی شده (۲)

در شماره قبل به لایه های این نوع رویکرد به اختصار اشاره شد. طی این شماره و شماره های بعد به...

رویکردی عملی به امنیت شبکه لایه بندی شده

امروزه امنیت شبکه یک مسأله مهم برای ادارات و شرکتهای دولتی و سازمان های کوچک و بزرگ است. تهدیدهای...

نفوذ ویروس در ایمیل

شما صرفا با خواندن يك متن سادة e-mail يا استفاده از netpost ، ويروسي دريافت نخواهيد كرد. بلكه...

رویکردی عملی به امنیت شبکه لایه بندی شده (۳)

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