مبتدی (مناسب برای درک مفهوم کلی مطلب)

F2161

اهداف اصلی ما پیشنهاد یک چارچوب استفاده از تکنولوژی بلاک چین برای ایجاد یک آرشیو شخصی می باشد که همراه با گواهی است. این آرشیو هویت، دقت و شفافیت را حفظ می کند در حالیکه از حریم خصوصی محافظت می کند. مفتشان دیگر موردنیاز نیستند. فاعل می تواند تصمیم بگیرد که چه چیزی را در اختیار چه کسانی و در چه هنگامی براساس ماهست درخواست قرار دهد. وقتی که یک درخواست بیشتر از یک دستاورد دانشگاهی می-باشد، هرگونه PDAهای همراه با چنین تگ (برچسب)، می توانند قفل شکنی شده و در دسترس قرار گیرند. وقتی که یک درخواست در ارتباط شناسایی هویت باشد، فاعل میتواند PDAهایی همانند بیومتریکها را قفل شکنی کند. مشتری میتواند به PDAها سریعا دسترسی پیدا کند و بر این اساس تصمیم گیری نماید. به علاوه، ابزارها و خدمات ارائه شده توسط PASS می توانند هرگونه پروژه مرتبط با رشد شخصی و جدول زمانی را بسیار آسانتر سازند.
بخش زیر آخرین توسعه مفهوم «اثبات X» را با استفاده تکنولوژی بلاک چین مرور می کند جایی که X می تواند هر چیزی همانند هویت، مالکیت دارایی، معامله خاص، درجه دانشگاهی، اطلاعات پزشکی و دستاوردهای آکادمیک باشد. بخش بعد PASS را بحث خواهد کرد، یک سیستم خدمات آرشیو شخصی که بر اساس آن فاعل می تواند آرشیوهای شخصی به طور زمان مند و دقیق ایجاد کند. آنها به گونه ای گواهی داده شدند که نیازمند اعتبارسنجی در هر بار استفاده نمی باشند. PASS فراگیر می باشد در حالیکه حریم خصوصی را حفظ می کند. آخرین بخش به بحث درباره شانس، چالشها و کاربردهای آینده اختصاص داده شده است.
2- مرور منابع و مراجع
مسائل اصلی ایجاد مصنوعات دیجیتال شخصی (PDAها) عبارتند از فرآیند اعتبارسنجی و قابلیت اعتماد. همانطور به لحاظ آماری در بخش1 نشان داده شد، بیش از 30 درصد کارجویان اطلاعات دیپلم خود را تغییر می دهند. 70 درصد در دستاورد خود اغراق می کنند [1].
تلاشهای متعدد برای ایجاد اعتبار و گواهی در کنار موفقیت دانشگاهی انجام شدند. ایده Open Badge یکی از آنها می باشد. گروه کاری استاندارد برای Open Badgeها همانطور که در وبسایت آن عنوان شده است [2]، مهارتها و دستاوردها را به وسیله ارائه نمادهای بصری همراه با داده های قابل تائید و شواهدی که می توانند در وب به اشتراک گذاشته شوند، مبادله می کنند. Open Badgeها فاعل را برای مدیریت دستاوردهای یادگیری آنها توانمند می سازد. هدف این گروه کاری استانداردسازی بیشتر ملاحظات می باشد که انطباق با آنها، حفاظت از آنها و ایجاد آنها بسیار واضح تر و آسانتر می باشد. آکلیم [3] پلتفرم نشان گذاری دیجیتال براساس استاندارد Open Badge بوده و توسط پیرسون ارائه شده است. آکلیم میلیونها امضاء از سازمانهای مشهور همانند IBM برای دستاوردهای پیشرفت شغلی صادر کرده است که به حرفه ای شدن افراد کمک می کند. یک امضاء صادر شده از طریق آکلیم یک بازنمایی دیجیتال از نتیجه یادگیریف تجربه یا رقابت می باشد. این امضاها میتوانند به صورت آنلاین در یک شیوه ای که آسان و ایمن می باشد، به اشتراک گذاشته شده و تائید شوند. آنها محتوی اطلاعات دقیق می باشند که متون مرتبط درباره چیزی دقیقا حاصل شده است، فراهم می کنند که کدام سازمان دستاورد را شناسایی می کند و چه فردی این شناسایی را به دست اورده است. خدمات ارائه شده شایستگی های مربوط به خود را دارا می باشندو نقص اصلی مدل متمرکز آن می باشد.
آموزش جهانی سونی اعلام می کند که تکنولوژی را با استفاده از بلاک چین برای اشتراک آزاد مهارت دانشگاهی و رکوردهای پیشرفته در سال 2016 توسعه خواهد داد [4]. آنها هدف استفاده از خصوصیات ایمن بلاک چین برای تحقق انتقال رمزگذاری شده داده ها همانند اطلاعات مهارتی دانشگاهی فرد و سنجشهای پیشرفت بین دو نهاد معین دارند. جریان کار حقیقی هنوز در حال مشاهده می باشد و نیازمند آزمایش است.
سیستم ID یک مسئله طولانی مدت می باشد. W3 هفت الزام عمومی برای خدمات مدیریت هویت جهانی شناسایی می کند [9]: قابلیت حمل و قابلیت همکاری، قابلیت بسط و توسعه، حریم خصوصی و امنیت مذاکره شده، مسئولیت پذیری، قدرت ثبت توزیع شده، قدرت گواهی توزیع شده و قدرت مدیریت مستقل. چنین سرویسی باید از شناساگرهای منحصر به فرد جهانی در یک فرمت تبادل مشترک استفاده کنند، نگاشت قابل بسط برای این شناساگرها از دیگر شناساگرهای استفاده شده معمول و از یک پروتکل مشترک برای اثبات و احراز هویت یک هویت جهانی استفاده کنند. این باید تعریف واژگان جهانی و نیز تعریف واژگان محلی توزیع شده را پشتیبانی کند. این نیازمند پشتیبانی ناشناسی و نام مستعار برای حفاظت حریم خصوصی می باشد. بنابراین، ناشناسی و ناشناسی دروغین (نام مستعار) برای حفاظت حریم خصوصی تحت صلاحیت حریم خصوصی و امنیت می باشد.
سیستم ID باید هردوی مدلهای ثبت سلسله مراتبی و همتا به همتا (یا نظیر به نظیر) را پشتیبانی کند. نهاد مدریت کننده باید به صورت یک سازمان ناسود آور بین المللی تعیین شود بنابراین در تمام جوانب به لحاظ دولتی، صنعتی و فروش بی طرف می باشد. این سازمان باید هردوی استانداردهای فنی و عملیاتی برای خدمات را برآورده کند از آنجایی که این دو مورد به طور نزدیکی آمیخته به یکدیگر می باشند. این سازمان باید توسعه واژه جهانی برای ویژگیهای هویت عمومی و ساختارهای کنترل پروتکل جهانی را مدیریت کند. این سازمان باید قوانین مسئولیت پذیری را برای تمام عوامل از جمله نهادهای ثبت و صدور گواهی برآورده کند. این سازمان باید به عنوان یک نهاد بنیادی غیرنسبی برای ثبت سلسله مراتبی یا مدلهای صدور گواهی عمل کند.
OpenID با اتصال OpenID [6 تا 11] برای تعریف و توسعه یک استاندارد باز و پروتکل احراز هویت غیرمتمرکز می باشد. این مورد نهادهای متکی (RP) برای اعتبارسنجی هویت کاربر نهایی براساس احراز هویت انجام شده توسط ارائه کننده OpenID (OP) یا سرور احراز هویت و نیز برای دستیابی به اطلاعات پروفیال بنیادین درباره کاربر نهایی در یک شیوه متقابل و همانند REST توانمند می سازد. با انجام احراز هویت کاربران از طریق یک سرویس شخص ثالث، این مورد نیاز برای وب مسترها جهت ارائه سیستم های ادهاک خود آنها و هویت و پسورد مجزا حذف می کند.
در حالیکه OAuth سرویس احراز هویت شخص ثالث را توانمند می سازد، هنوز از نظر ارائه کننده OpenID متمرکز می باشد. و کاربران باید اطلاعات خصوصی بسیاری را در دسترس قرار دهند تا احراز هویت شوند. این همچنین دارای یک نقطه شکست مجزا می باشد. به علاوه، این همچنین برخلاف ماهیت اینترنت می باشد که نهاد مرکزی مجزا می باشد که کنترل را انجام می دهد، چه کسی میتواند چه چیزی را انجام دهد.
اطلاعات خاص بیومتریک متعدد میتوانند برای شناسایی انسان با دقت بسیار بالا استفاده شوند [8، 32، 33]. این به خصوص در اپلیکیشنهای رسانه اجتماعی مفید می باشد که در آن کاربر میتواند ناشناس باشد اما نیاز است تا به صورت یک انسان حقیقی به جای یک دسته از باتهای اجتماعی استامپ (برچسب) شود. بنابراین، نتایج همانند احساسات یا نظرسنجی از اپلیکیشن رسانه اجتماعی میتوانند شرایط حقیقی را بیان کنند و توسط باتهای اجتماعی دچار سردرگمی نشوند.
برخی اپلیکیشنهای وب همانند taskstream (جریان مسئولیت) یک پلتفرمی را برای کاربر جهت ایجاد نمونه های شخصی فراهم می کنند. این میتواند پیشرفت در پروژه های خاص را ردیابی کند و بازتاب موضوعات خاص را ثبت کند. این اپلیکیشنها میتوانند به عنوان یک شیوه ای برای نشان دادن اثر رشد شخصی عمل کنند که میتواند منشاء مهارتهای خاص را فراهم کند.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

با در نظر گرفتن تمام این چالش ها و به واسطه تحلیل سناریوهای ابری و بین ابری (جینت، 2010؛ جیسرز،2010؛ ان جی او و همکاران،2011، 2012) ؛ و همچنین پژوهش های مرتبط به کنترل دسترسی برای رایانش ابری (آمازون، 2013؛ برنال برناب و همکاران،2012؛ بسنکورت و همکاران، 2007؛ کالرو و همکاران، 2010؛گویال و همکاران،2006؛ جین و همکاران، 2014؛ ساهای و واتر، 2005، 2005؛ تانگ و همکاران، 2013) ، ما به معرفی روش کنترل دسترسی ویژگی محور چندمستاجری (MT-ABAC) پرداخته، که به مدلسازی ABAC بکارگرفته شده برای الگوی چندمستاجری می پردازیم. هدف از آن نه تنها مدیریت منابع و مدخل ها به صورت انعطاف پذیر و مقیاس پذیر ABAC است، بلکه شامل محدودیت های روش مرتبط به منظور تسهیل همکاری و دادن مجوز میان مستاجران و کاربران در سطوح چندگانه است. این مدل تعمیم یافته برای سناریوهای بین ابری با روش تبادل نشانه گذاری برای ایجاد اعتماد پویا در سطوح پایین تر است. به منظور تسهیل ارزیابی و پیاده سازی روش ویژگی محور، مکانیسم موثری را برای تبدیل عبارات منطقی پیچیده در سیاست ها، به نمودارهای تصمیم فشرده، بکار می گیریم. نمونه اولیه ما در ارتباط با سیستم کنترل دسترسی چندمستاجری برای محاسبات بین ابری ایجاد و تست شده و در پروزه جیسرز ادغام شد. ارزیابی ها نشان داد که سیستم ما دارای عملکرد مناسبی از نقطه نظر تعداد منابع ابری، کلاینت ها و سیاست ها، است.
مابقی مقاله، به صورت زیر بخش بندی می گردد، بخش 2، به بررسی پژوهش های مرتبط با کنترل دسترسی برای رایانش ابری، رمزنگاری براساس ویژگی (ABE) و اختیارات توزیع شده می پردازد. بخش 3، شامل مقدماتی در ارتباط با مدل های اطلاعات ابری و ABAC پایه است. این موضوعات برای تدوین روش مورد نظر ما در بخش 4، بکار گرفته می شوند. مدل پیشنهادی، در بخش 5، تحلیل و ارزیابی می گردد. بخش 6 مکانیسمی را به منظور مدیریت کارآمد شرایط در مدل ما، به بحث می گذارد. همچنین، در بخش 7، مدل خود را برای سناریوهای بین ابری، تعمیم می دهیم. بعد از ان، بخش 8 و 9 حاوی طراحی، پیاده سازی و ارزیابی نمونه اولیه در پروژه جیسرز است. در نهایت، بخش 10، نتیجه گیری مقاله را نشان می دهد.

2. پژوهش های مرتبط
چندین رویکرد و روش در زمینه کنترل دسترسی به مدیریت خدمات ابری مطرح شده است. بر اساس مدل اطلاعاتی مشترک (CIM)، محققاتی چون برنال برناب و همکارانش (2012) و کالرو و همکاران (2010) مدل RBAC را در ترکیب با cim مطرح نمودند. در این پژوهش، دستور تایید شده ای که بر مبنای چهار جزء (صادرکننده، موضوع، مزیت، منابع) تعریف می گردد، به صورت یک قانون با استفاده از زبان قوانین وب معنایی (SWRL) نوشته شده است (هوروک و همکاران، 2004). این قانون سپس توسط استدلال گر DL مد نظر قرار گرفته تا به دستور RDF تبدیل گردد. برنال برنابی و همکارانش (2012) توضیح دادند که این امکان وجود دارد تا از مدل پیشنهادی برای پشتیبانی از خصوصیات RBAC برای کاربران منتفع، استفاده کرد. همکاری های بین مستاجری، توسط اطلاعات بافتی مشترک ارائه شده، به گونه ای که فرد متولی می تواند به تعریف دستورات تاییدی بپردازد. به هر حال، آن ها به پشتیبانی از نمایندگان سطح چندگانه در میان مستاجرها نپرداخته و همچنین تفکیک اعتماد بین مستاجرها محدود است. علاوه بر این، سیستم های ابری با در نظر گرفتن تعداد منابع و موضوعات ( مستاجران و کاربران) و پیچیدگی روش ها با توجه به تعداد دستورات تایید شده، افزایش داشته است، مکانیسم استدلال کننده DL در زمانی که تعداد دستورهای RDFافزایش یابد، می تواند یک مشکل بلقوه باشد. علاوه بر این، از طریق بکارگیری روش OWL DL (SWRL) به عنوان زبان کنترل دسترسی، انعطاف پذیری و بیانگری زبان مربوطه، در مقایسه با زبان هایی همچون XACML، محدود است.
کنترل دسترسی نقش محور چندمستاجری (MT-RBAC)(تانگ و همکارانش، 2013) ، به تعمیم روش RBAC پایه، با مجموعه ای از مدل ها با توجه به ویژگی های مدیریتی، پرداختند. علاوه بر مجوزهای معمول بین مستاجری و عملیات تخصیص نقش، همکاری های بین مستاجری از طریق نقش های اشتراکی به اجرا در می آید. مستاجر اعتباردهنده می تواند به تعریف تمام نقش های مرتبط با مستاجر امانت دار (MT-RBAC0)، نقش های عمومی مشابه برای تمام امانت گیرندگان (MT-RBAC1)، یا نقش های تفکیک شده برای امانت داران مختلف (MT-RBAC2)، بپردازد. در عوض، امانت دار می تواند به پیاده سازی دو فعالیت مدیریتی بپردازد: i) تعیین کاربر در بین کاربرانش و ii) زنجیره نقش در مورد نقش های مشترک. الگوی نمونه، با استفاده از زبان ویژگی محور XACML با الحاق نمایه RBAC به اجرا در آمد. حتی اگر MT-RBAC به حل مشکلات کنترل دسترسی برای فرایند چندمستاجری با استفاده از RBAC بپردازد، ولی دارای مشکلاتی در موضوعات کنونی RBAC در ارتباط با مقیاس پذیری و انعطاف پذیری است. همچنین مدل پیشنهادی شامل محدودیت های روش مورد نظر ما، برای پشتیبانی از جداسازی و جلوگیری از تضاد روش ناست.
جین و همکارانش (2014) ، مدل ABACجین و همکاران (2012) را به سناریو Iaas، تعمیم دادند. در مدل آن ها، مدخل ها؛ به کاربران اصلی خدمات ابری که می تواند به مدیریت زیرساخت مجازی (VI) و مستاجران بپردازند؛ و کاربران اصلی مستاجر که می توانند به پیکره بندی پروفایل خصوصیات و مدیریت کاربران ادمین مستاجر بپردازند؛ کاربران ادمین مستاجر که می توانند به مدیریت کاربران عادی مستاجر بپردازند و در نهایت، کاربران عادی مستاجر که می توانند بر روی منابع ابری فعالیت داشته باشند، تقسیم بندی می شود. با استفاده از زبان روش تعریف شده در نظریه جین و همکارانش (2012) ، نمونه اولیه در سیستم اُپن استَک ادغام شد. اگرچه این روش از ABAC برای پیاده سازی سناریوهای چندمستاجری، استفاده کرده است، مدل آن، از مشکلات تضاد روش در فرایند چندمستاجری، در زمانی که مدخل های چندگانه می توانند به تعریف روش ها بپردازند، آگاه نیست. بنابراین، آن ها شامل جداسازی نشده و محدودیت های را برای سیاست هایی که در رویکرد ما وجود دارد ایجاد کرده، که منجر به حل مشکلات روش تضاد می گردد. علاوه بر این، مدل آن ها به تعریف همکاری بین مستاجرها نمی پردازد.
به منظور حفاظت از داده در محیط برون سپاری همچون محیط های ابری، پژوهش ABE(بتنکورت و همکارانش، 2007؛ گویال و همکاران، 2006؛ ساهای و واترز، 2005) برای امنیت ذخیره سازی برون سپاری مطرح شد، درحالیکه رمزنگاری همریختی (براکرسکی و وایکونتانتان 2011؛ اسمارت و ورکاتران، 2010) مطرح شد تا به تامین امنیت محاسبات بر روی سیستم های متخاصم بپردازد. در روش ABE کلید سیاست (KP-ABE)(گویال و همکارانش، 2006) ویژگی هایی را درخواست داده اند که مرتبط با متنهای رمزگذاری شده بود، و روش ها مرتبط با کلیدهای کاربر بوده است. طرح ABE روش متن رمزگذاری شده (CP-ABE (بتنکورت و همکارانش، 2007) مکانیسمی را ایجاد می کند که امکان ایجاد کلیدهای کاربر را، بر مبنای ویژگی هایشان و سیاست های ویژگی- محور به منظور حفاظت از داده هایی فراهم کرده که مرتبط با متون رمزدار هستند. طرح های ABE به منظور تامین امنیت داده بر روی خدمات ذخیره سازی ابری، توسعه و بکار گرفته شدند (لی و همکاران، 2013؛ یو و همکاران،2010) . اگرچه رمزگذاری همریختی باعث ایجاد قابلیت اعتماد در محاسبات برون سپاری می گردد، کاربردهای ان در رایانش ابری، به دلیل پیچیدگی و عملیات بالاسری همچنان محدود است(نائریگ و همکاران، 2011) . تمام این مکانیسم های نهفته به صورت AEF در چارچوب کنترل دسترسی ISO 10181-3(ISO, 1996)، مد نظر قرار گرفته، درحالیکه پژوهش ما تمرکزش را بر روی موئلفه های تصمیم کنترل دسترسی قرار می دهد. بنابراین، ABE و رمزگذاری نهفته، منطبق با طرح پیشنهادی ما است.
هویت AWS آمازون و مدیریت دسترسی (IAM) (آمازون، 2013) ، ترکیبی از سیستم مدیریت و یک مکانیسم کنترل دسترسی است. به دنبال نام نویسی نسبت به هر یک از محصولات AWS آمازون، برای هر مشتری، یک حساب استیجاری AWS تخصیص داده می شود. سپس، تمام عملیات بر روی محصولات AWS ، محدود به این حساب می گردد. سیستم IAM آمازون، مکانیسمی را برای ایجاد و مدیریت چندین کاربر متصل به حساب استیجاری AWS ، ایجاد می کند. با استفاده از روش های تایید جیسون- استایل که در سمت IAM ذخیره شده، یا در سمت محصولات AWS الحاق می گردد، سیستم IAM می تواند به کنترل فعالیت های کاربری بر روی منابع AWS بپردازد. به منظور تضمین شرایط امنیتی در مورد اعتمادسازی و یکپارچگی، به کاربران، اعتبار امنیتی اختصاصی برای دسترسی به منابع AWS تخصیص داده می شود. به هر حال، زبان روش پشتیبانی در سیستم IAM آمازون، با توجه به سیاست ساده ویژگی محور با خصوصیات RBAC محدود، گویا نیست. دسترسی فراتر از حساب، از طریق ایجاد سیاست سیستم IAM حساب امانت گذار به حساب امانت دار، تعریف می گردد. سپس امانت دار می تواند، مزایای مربوطه را به کاربرانش تخصیص دهد. این روش از همکاری های فراحساب چندسطحی، پشتیبانی نمی کند.
چارچوب مجوز OAuth (دی هارد و رکوردون (2012) ، این امکان را به شخص ثالث می دهد تا به منابع HTTP از طریق تایید صاحب داده، به واسطه نشانه گذاری ها، دسترسی پیدا کند. این چارچوب، پروتکل گردش کار را، برای مجوز توزیع که در حال حاضر در خدمات ابری مختلف بکار گرفته می شود همانند Google APIs و Twitter APIs (رابط برنامه کاربری گوگل و رابط برنامه کاربری توییتر)، فراهم می کند. به هر حال سیستم OAuth 2.0، از هیچ مکانیسم نهفته ای استفاده نکرده بلکه امنیتش بر مبنای HTTPS قرار داده، که این مورد در سناریوهایی که کلاینت از پروکسی ها استفاده می کند یا دارای ارتباط مستقیم با منابع نیست، دارای انعطاف پذیری نیست.
در مقایسه با پژوهش های مرتبط، طرح مورد نظر ما، به حل مشکلات کنترل دسترسی برای چندمستاجری بطور کامل تر می پردازد. ما به تدوین روش ABAC در مدل چندمستاجری از طریق تفکیک و ایجاد محدودیت، به منظور اجتناب تضاد روش پرداختیم. روش ما، همچنین به پشتیبانی از همکاری های انعطاف پذیر بین مستاجرها با سطوح چندگانه اعطای مجوز می پردازد. مدل تعمیم یافته مورد نظر ما برای محاسبات بین ابری، از روش تبادل نشانه هااستفاده کرده که برای MT-ABAC طراحی شده، که به هماهنگ سازی محدودیت ها و پیاده سازی مکانیسم های نهفته به منظور حل توزیع مجوز با در نظر گرفتن موضوعات محدود اعطای مجوز پرداخته که برای روش مورد نظر ما مناسب تر از چارچوب OAuth 2.0 کنونی است.

3. مقدمات
به منظور حل چالش های ذکر شده در کنترل دسترسی برای سیستم های مدیریت منابع ابری، مدل MT-ABAC مورد نظر ما، شامل ویژگی های زیر است.
• تنوع حمایتی موضوعات: نهادهای مختلف قادر به ترکیب سیاست ها برای مدیریت اهدافشان، همانند ارائه دهندگان خدمات ابری، مستاجر ثبت نامی و مستاجر مشترک است.
• کنترل دسترسی ریزدانه ای بر مبنای مدل ABAC
• همکاری های انعطاف پذیر بین مستاجری که این امکان را به مستاجر ها می دهد تا به اشتراک منابع ابری تعهد شده، در سطوح چندگانه بپردازند
• محدودیت های پویای اعمال شده به منظور مدیریت رئش برای چندین فرد ذیصلاح: ما به تعریف محدودیت های تفکیکی و اععطایی به منظور کنترل این امر می پردازیم که آیا روش های بروز شده سازگار با ویژگی های مدیریتی روش چندمستاجری است یا خیر. این تضمین، زمانی که هیچ تضادی در طی ارزیابی زمان اجرا روی نمی دهد، باعث بهبود عملکرد سیستم می گردد. پژوهش های قبلی انجام شده توسط کالرو و همکارانش،2010؛ برنال برناب و همکاران، 2012؛ تنگ و همکاران، 2013؛ جین و همکاران،2013؛ از این ویژگی را مد نظر قرار نداده است.
• سیاست گذاری بر اهداف پویا: در سیستم های ابری، منابع ابری مورد بحث، به عنوان اهداف دادن مجوز است. شناسه های ان در طی مراحل تامین، ایجاد شده، و در پایان مرحله ثبت نام به اتمام می رسدو ارائه دهندگان خدمات ابری به طور اتوماتیک نیازمند تعریف دستور مجوز برای اهداف، بر طبق به ویژگی سلف سرویس درخواستی، است.
• مدل مورد نظر ما، به منظور ادغام با مدل اطلاعاتی منابع تعریف شده که می تواند برای ایجاد سیاست ها، از الگوهای سیاست از پیش تعریف شده، در ترکیب با طرح های خدمات ابری استفاده کند.
در سناریوهای زیر، ابتدائا به تعریف مدل اطلاعاتی مورد استفاده برای مدیریت منابع ابری در سناریو مان در پروژه جیسرز (جیسرز، 2010) و مدل ABAC پایه می پردازیم. بر اساس مدل پایه ABAC، به تعریف مدل MT-ABAC در بخش 4 می پردازیم.

مبتدی (مناسب برای درک مفهوم کلی مطلب)

F1861

حمله واکنش. این حمله می تواند به صورت حمله متن رمزی-انتخاب شده (CCA) رده بندی شود، اما از فرضی ضعیف تر از CCA استفاده می کند [12]: حریف تنها واکنش دریافت کننده ای را مشاهده می کند که دارای کلید خصوصی است، اما نیاز به دریافت متن مهنادار رمزگشایی شده آن ندارد (حمله مشابه به طور مستقل در [28] پیشنهاد می شود). در این حمله، یک حریف، متون مهنادار متناظر را دریافت می کند. بنابراین این حمله به صورت CCA رده بندی می شود.
ایده این حمله به صورت زیر است. حریف یک یا چند بیت از متن رمزی هدف c را برعکس می کند. در نظر بگیرید که c’ نشاندهنده متن رمزی برعکس شده باشد. حریف c’ را به دریافت کننده مناسب انتقال می دهد و واکنش او را مشاهده می کند. واکنش های گیرنده می تواند به دو رده تقسیم شود:
واکنش A: به علت خطای غیرقابل تصحیح یا به علت متن مهنادار بدون معنی، درخواست تکرار را به حریف بازگردانید.
واکنش B: یک تشکر را بازگردانید یا هیچ کاری انجام ندهید زیرا متن مهنادار مناسب m رمزگشایی شده است.
اگر وزن کلی بردار خطا از t بعد از برعکس نمودن تجاوز نکند، واکنش B مشاهده می شود. در غیراینصورت واکنش A مشاهده می شود. بنابراین با تکرار مشاهدات بالا، زمان های چندجمله ای n، حریف می تواند بردار خطا را تعیین کند. زمانی که بردار خطا تعیین شود، متن مهنادار متناظر به اسانی با استفاده از حمله GISD رمزگشایی می شود.
حمله قابلیت انعطاف. این حمله حریف را برای عوض کردن هر بخش از متن مهنادار متناظر برای هر متن رمزی داده شده c بدون شناختن متن مهنادار m مجاز می سازد، یعنی حریف می تواند یک متن رمزی جدید c’ را تولید کند که متن مهنادار آن از هر متن رمزی معین بدون شناختن m است [13,28].
این حمله به صورت زیر توصیف می شود. در نظر بگیرید که G’[i] نشاندهنده سطر iام ماتریس عمومی G’ و نشاندهنده مجموعه ای از مختصات ij باشد که مقدار ان در 1 است. متن رمزی c’ به صورت زیر محاسبه می شود

این حمله به ما می گوید که McEliece PKC غیرانعطاف پذیر بودن را برآورده نمی سازد [6]. حتی در مقابل حملات مجهول، مانند حملات متن مهنادار انتخاب شده. و بنابراین تحت سناریوی متن رمزی انتخاب شده که در آن یک حریف می تواند یک پیشگویی رمزگشایی را برای رمزگشایی تعداد چندجمله ای متون رمزی درخواست نماید (به استثنای متن رمزی چالش c)، حریف می تواند هر متن رمزی داده شده c را با روش زیر رمزگشایی نماید. اول حریف پیشگویی برای رمزگشایی c’ را درخواست می کند، سپس پیشگویی را درخواست می کند. لذا، او می تواند متن مهنادار هدف c را با بازیابی کند.
4 تبدیلات برای McEliece PKC
همانطور که در بخش 3 ذکر شد، بدون هر پیشگویی رمزگشایی و هر دانش جزئی در مورد متن مهنادار متناظر برای متن رمزی چالش، هیچ الگوریتم چندجمله ای-زمانی برای تبدیل McEliece PKC شناخته شده نیست (که پارامترهای آن به دقت انتخاب می شوند). تحت این فرض که این مسئله تبدیل سخت است، این مسئله می تواند به مسئله ای سخت برای شکستن قابلیت تشخیص رمزگذاری در مقابل حملات بحرانی تبدیل شود (یا به طور کلی تر در مقابل حملات متن رمزی انتخاب شده تطبیقی) با معرفی تبدیلات مناسب در کد پیشگویی تصادفی. در این بخش، ما بررسی می کنیم که تبدیلات برای McEliece PKC مناسب هستند و اینکه نیستند.
4.1 دستورات
ما از دستورات زیر در این مقاله استفاده می کنیم:
C(n,t): تعداد ترکیبات با اتخاذ t از n عنصر
Prep(m): پیش پردازش برای یک پیام m مانند فشردگی داده ها، مسیر داده ها و غیره. معکوس آن به صورت نشان داده می شود.
Hash(x): تابع هش یک راهه برای رشته دودویی با طول دلخواه x برای یک رشته دودویی با طول ثابت. زمانی که حوزه خزوجی Zn که در آن N=C(n,t). ما از Hashz(x) به جای Hash(x) استفاده می کنیم.
Conv(z): تابع Bijective که یک عدد صحیح را تبدیل می کند که در آن N=C(n,t) به بردار خطای متناظر z. معکوس آن به صورت نشان داده می شود.
Gen(x): تولیدکننده دنباله های شبه تصادفی امن رمزنگاری با طول دلخواه از بذر طول ثابت x.
Len(x): طول بیت x.
Msbx1(x2): بیت های x1 چپ x2.
Lsbx1(x2): بیت های x1 راست x2.
Const: ثابت از پیش تعیین شده استفاده شده در کل
Rand: منبع تصادفی که دنباله تصادفی صحیح (یا شبه تصادفی قابل تشخیص محاسباتی) را تولید می کند.
: رمزگذاری x با استفاده از McEliece PKC با بردار خطای z.
: رمزگشایی x با استفاده از McEliece PKC اصلی

4.2 تبدیلات نامناسب برای McEliece PKC
تبدیل OAEP. در [2] Bellar و Rogaway یک تبدیل عام به نام OAEP را پیشنهاد نمودند (پد رمزگشایی نامتقارن بهینه) که OWTP (جایگشت Trapdoor تک راهه) مانند اولیه RSA را به PKC تبدیل می کند که در مقابل حملات متن رمزی انتخاب شده تطبیق غیرقابل تشخیص است (CCA2). McEliece PKC با این تبدیل OAEP در شکل 1 نشان داده شده است. متاسفانه، این تبدیل به طور صحیح کار نمی کند زیرا حمله واکنش هنوز قابل کاربرد است. این بدین معنی نیست که تبدیل OAEP دارای خطا است، اما McELiece اولیه یک جایگشت نیست.
تبدیل ساده Fujisaki-Okamoto. در [8]، Fujisaki and Okamoto یک تبدیل ساده و عام را از PKC پیشنهاد نمودند که در مقابل CPA (حملات متن مهنادار انتخاب شده) در یک PKC قابل تشخیص نیست که در مقابل CCA2 قابل تشخیص نیست. McEliece PKC با این تبدیل در شکل 2 نشان داده شده است. متاسفانه، این تبدیل به درستی کار نمی کند زیرا حمله متن مهنادار جزئی شناخته شده به درستی کار می کند مگر اینکه Len(r) نزدیک به k باشد.
این بدین معنی نیست که تبدیل ساده Fujisaki-Okamoto دارای خطا است، اما McEliece PKC حتی در مقابل CPA قابل تشخیص است. هر حریف مجهول (که از پیشگوییی رمزگشایی استفاده نمی کند) می تواند حدی بزند که کدام پیام m0 و m1 متن مهنادار متناظر متن رمزی معین c برای McEliece PKC اصلی با دیدن اینکه آیا وزن mbG ⊕ c¯ is t است یا خیر که در آنb ∈ {0, 1}.