دانلود رایگان ترجمه مقاله احراز هویت پرداخت الکترونیکی (اسپرینگر ۲۰۱۴)

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

نقص اصلی امنیتی پیاده‌سازی‌های ۳D-Secure، که در [۱۹] تأکید شده است، مربوط به تأیید هویت کاربر (مرحله ه) است. برخی از بانک‌ها در گذشته از تاریخ تولد یا دیگر موارد استفاده می‌کردند. بسیاری از بانک‌ها این راه‌حل‌ها را با یک مکانیزم احراز هویت قوی جایگزین کرده‌اند (به‌عنوان مثال پیامی به تلفن همراه کاربر فرستاده می‌شود) و سپس دو عامل تأیید اعتبار (براساس داشتن مالکیت) تلفن‌همراه و دانستن کد PIN برای دسترسی منطقی به آن) مطرح می‌شود. با این حال ما استدلال می‌کنیم که طرح تأیید اعتبار کاربر آسیب‌پذیری قابل توجهی دارد. بنابراین یک رویکرد جدید مبتنی بر بیومتریک پیشنهاد می‌کنیم که این آسیب‌پذیری‌ها را از بین ببرد.
راه‌حل‌های تأیید هویت کاربر، که به‌عنوان خوانندگان CAP، تولیدکنندگان TAN یا سیستم سبک وزن در [۱۷] پیشنهاد شده‌اند، رویکردهای مبتنی بر دانش هستند. بنابراین استدلال می‌کنیم که فقط بیومتریک می‌تواند کاربران را تصدیق کند، درحالی‌که راه‌حل‌های مبتنی بر دانش و اختیار، تنها تأیید اعتبار غیرمستقیم کاربران را برعهده دارند. دلیل اصلی مربوط به ارتباط خاص بین کاربر و تأییدکننده است البته مشکلات خاص مربوط به بیومتریک، در زیر ذکر شده است:
• داده‌های بیومتریک بسیار حساس هستند زیرا نمی‌توانند به طور کلی لغو شوند. رمزگذاری آن ضروری است اما کافی نیست (همانگونه که داده‌ها باید برای تطبیق فرآیند در حالت کلی رمزگشایی شوند و طول عمر داده بسیار بالا است). به همین دلیل استفاده از مرکز ذخیره‌سازی داده‌های بیومتریک مشکل‌ساز است.
فرآیند تطبیق می‌تواند اشتباهات واقعی به هنگام راهنمایی کاربران ایجاد کند و افراد متخلف می‌توانند به اشتباه پذیرفته شوند. این مسئله برای تأیید رمز عبور تا زمانی که رمز صحیح تایپ شده است درست نیست (اما هیچ اثباتی وجود ندارد که توسط کاربر واقعی تایپ شده است).
• داده‌های بیومتریک را می‌توان در حین انتقال آن متوقف کرد. این امر می‌تواند به مشکلات امنیتی منجر شود، مانند حملات پاسخ و حملات حریم خصوصی براساس قابلیت اتصال. به همین علت، داده‌های بیومتریک باید قابل لغو و پویا باشمد (تغییر در هر تراکنش).
در این مقاله، یک راه‌حل جدید را پیشنهاد می‌کنیم که این مشکلات را حل می‌کند. برای دستیابی به یک راه‌حل استاندارد امنیتی و حفظ حریم خصوصی، دو عنصر را ترکیب می‌کنیم: یکی از آنها یک دستگاه خاص متعلق به کاربر به نام OffPAD است و دومی پروتکل استفاده از بیومتریک و الگوریتم‌های قابل لغو است. در بخش بعدی، لیستی از نیازمندی‌های امنیتی و حریم خصوصی را از راه‌حل پیشنهادی بیان می‌کنیم.

۳٫ الزامات امنیتی و حفظ حریم خصوصی
در پرداخت الکترونیکی، چهار عامل اصلی حضور دارند: کاربر C، که دارای OffPAD است، می‌خواهد یک سرویس آنلاین با یک کارت اعتباری، از طریق وب سایت ارائه دهنده خدمات SP خریداری کند. کاربر دارای یک بانک صادرکننده و SP یک بانک خریدار دارد. در این مقاله ارائه‌دهندگان پرداخت را بانک کاربر و بانک SP می‌نامیم. عامل پنجم اغلب درگیر است. این عامل به عنوان شخص ثالث صندوقدار یا دایرکتوری مورد استفاده در ۳D-Secure مورداعتماد است. نقش عامل پنجم متفاوت است، اما به طورکلی امکان تایید هویت بانک‌ها را فراهم می‌کند. پروتکل پیشنهادی بر روی احراز هویت کاربر و ثبت نام کاربر با SP تمرکز دارد.
در طول پرداخت آنلاین، اطلاعات شخصی متعددی درگیر هستند و باید در برابر چندین تهدید محافظت شوند [۴]. برای حفظ خصوصیات امنیتی و خصوصی، یک لیست از ده مورد الزامات RI تعریف شده است. این الزامات باید در طول احراز هویت / ثبت نام کاربر در معماری پرداخت الکترونیکی در نظر گرفته شوند:
• R1: محرمانه بودن تراکنش‌ها نیازمند آن است که هر کدام از داده‌های مبادله به منظور حفاظت در برابر نهادهای خارجی رمزگذاری شوند.
• R2: یکپارچگی اطلاعات منتقل شده، دقت محتوا و به همین ترتیب تغییر داده‌ها در حین انتقال یا ذخیره‌سازی را ممکن می‌کنند.
• R3: احراز هویت کاربر توسط یک شخص مورد اعتماد، هویت مشتری بسته به وضعیت را تضمین می‌کند، احراز هویت می‌تواند به لطف داده‌های بیومتریک تحقق یابد.
• R4: تأیید اعتبار دستگاه کاربر، معتبر بودن دستگاه در نرم افزار را تایید می‌کند. این احراز هویت می‌تواند به لطف یک شناسه دستگاه تحقق یابد.
• R5: ثابت می‌کند که دستگاه متعلق به کاربر تضمین می‌کند دستگاه را از حملات جایگزینی دستگاه حفظ می‌کند.
• R6: تأیید هویت SP توسط کاربر یا توسط یک بخش مورد اعتماد، هویت SP را تضمین می‌کند.
• R7: تأیید اعتبار بانک توسط یک شخص مورد اعتماد هویت بانک SP و بانک مشتری را تضمین می‌کند.
• R8: عدم پیوند تراکنش‌ها مانع پیوند تراکنش‌های مختلف از همان مشتری می‌شود.
• R9: محرمانه بودن اطلاعات مشتری CI (اصل کمینه سازی داده) تنها دسترسی افراد مجاز به این اطلاعات را تضمین می‌کند. این مورد به بیومتریک داده‌های کاربر نیاز دارد که برای بانک‌ها و SP مشخص نیست.
• R10: حاکمیت اطلاعات بدین معنی است که اطلاعات شخصی مرتبط با مشتری می‌تواند تنها با کنترل پردازش و رضایت او انجام شود.
در بخش بعد، مفهوم OffPAD را به عنوان دستگاهی امن برای تضمین امنیت عملیات حساس معرفی می‌کنیم.

۴٫ مفهوم OFFPAD
PAD (دستگاه تایید شخصی) توسط Jøsang و Pope [13] به‌عنوان یک دستگاه امن خارجی برای پلت‌فرم کامپیوتر مشتری شرح داده شده است. PAD مفهومی پیشین از OffPADاست. OffPAD (دستگاه تأیید هویت آفلاین شخصی) توسط Klevjer و همکارانش [۱۶] و Varmedal و همکارانش توصیف شده است. [۲۶] که یک نسخه پیشرفته از PAD است و یک ویژگی اساسی برای تضمین امنیت آفلاین (ارتباطات ماشین به ماشین) است. OffPAD نشان‌دهنده مدیریت محلی هویت کاربر محور است زیرا امکان مدیریت امن و کاربرپسند را برای هویت‌های دیجیتالی و اعتبارات محلی بر روی کاربر فراهم می‌کند. OffPAD تأیید اعتبار هویت کاربر و ارائه‌دهنده خدمات (به‌عنوان مثال احراز هویت متقابل) را برعهده دارد و علاوه بر این می‌تواند تأیید اعتبار داده را نیز پشتیبانی کند. برای دسترسی به OffPAD، کاربر باید دستگاه را با استفاده از به عنوان مثال، یک پین، رمز عبور، بیومتریک یا سایر کافی اعتبارات احراز هویت باز کند. طراحی OffPAD در شکل ۲ نشان داده شده است.
OffPAD یک دستگاه قابل اعتماد است، به این معنی که طوری در نظر گرفته شده که در مقابل حملات مربوطه به اندازه کافی محافظت شده است. OffPAD اتصال محدودی به سیستم عامل مشتری دارد. بنابراین این کانال ارتباطات باید با دقت کنترل شوند، برای مثال با پاکسازی داده‌های دریافت شده. حفاظت در مقابل حملات به دنبال سرقت فیزیکی است که کنترل دسترسی سنتی بر اساس پین و بیومتریک، همراه با سطحی از مقاومت در برابر تهاجم فیزیکی دارد.
بااین‌حال، لازم نیست که سیستم عامل OffPAD و برنامه‌های کاربردی از آسیب‌پذیری‌هایی که به طور معمول در سیستم‌های آنلاین یافت می‌شود در امان باشند، زیرا فرض می‌شود که مهاجمان قادر به بهره‌برداری از چنین آسیب‌پذیری از OffPAD در اکثر موارد آفلاین هستند. بدین معنا که، باگ‌های خاص نرم‌افزاری که آسیب‌پذیری در یک سیستم آنلاین ایجاد می‌کنند به سختی در مورد آسیب‌پذیری در OffPAD صحبت می‌کنند زیرا نمی‌توانند مورد سوء استفاده قرار گیرند. OffPAD ممکن است دارای چندین رابط برای ارتباطات باشد. میکروفون و دوربین ممکن است برای تشخیص صدا و چهره استفاده شود تشخیصگر اثر انگشت می‌تواند برای تأیید هویت استفاده شود. الزامات آفلاین بودن با ارتباط الکترونیکی با OffPAD همراه نیست، اما به این معنی است که ارتباط فرمت‌ها کنترل شده و در مدت زمان کوتاه است. جدا شدن از شبکه‌ها امنیت دستگاه را بهبود می‌بخشد تا کمتر در مقابل حملات خارجی آسیب‌پذیر باشد.
هرگونه ارتباط الکترونیکی خاص باید به طور معمول قطع شود و فقط باید زمانی وصل شود که نیاز به احراز هویت یا مدیریت برای دستگاه NFC با اتصال USB پشتیبان مناسب برای اتصال OffPAD است. در اولین استفاده، هیچ روش رمزنگاری برای تأیید اتصال بین دستگاه و پلت فرم مشتری وجود ندارد، اعتماد باید به‌سادگی براساس تنظیم مشاهده شده باشد. در اولین اتصال، نوعی جفت شدن بین دستگاه و کامپیوتر اتفاق می‌افتد، به‌طوری‌که اتصالات بعدی می‌تواند تأیید شوند که بین دستگاه و رایانه مشابه باشند.
ما از این دستگاه امن برای بانکداری آنلاین و پرداخت الکترونیکی به همراه یک پروتکل اصلی با بیومتریک استفاده می‌کنیم. بخش زیر الگوریتم Biohashing مورد استفاده در پروتکل پیشنهاد شده را توضیح می‌دهد. سپس بخش ۶ جزئیات این پروتکل اصلی و جدید را بیان می‌کند.

۵٫ الگوریتم Biohashing
الگوریتم BioHashing بردار مقدار واقعی با طول n را (به عنوان مثال FingerCode، حاصل از یک روش استخراج ویژگی) به یک بردار دوتایی به طول m≤n(به عنوان مثال BioCode)، همانطور که توسط Teoh و همکارانش بیان شده است تبدیل می‌کند [۲۵].
این مسئله شامل طرح کردن FingerCode با یک پایه تعریف شده توسط یک seed تصادفی برای تولید BioCode است. تبدیل قالب از الگوریتم زیر استفاده می‌کند، که در آن ورودی‌ها تصادفی هستند و FingerCode F و خروجی BioCode B است:
۱) برای m≤n i=1,…,m بردارهای شبه تصادفی vi با طول n تولید می‌شود (از seed تصادفی) و در یک ماتریس شبه تصادفی جمع می‌شوند.
۲) الگوریتم Gram-Schmidt بر روی m بردار vi از ماتریس، برای تولید n بردار V_1,…,V_n اعمال می‌شود.
۳) برای m، i=1,…,m ضرب اسکالر p_i=<F,V_i> با استفاده از FingerCode F و m محاسبه می‌شود.
۴) در نهایت کد m بیتی (B0؛…؛ Bm)، با استفاده از فرآیند quantization زیر به دست می‌آید: هنگامی که برای احراز هویت BioCode مرجع استفاده می‌شود (محاسبه شده از FingerCode پس از ثبت‌نام و پس از نمایش مخفی) با BioCode ثبت شده (محاسبه شده از FingerCode محاسبه شده پس از ثبت جدید) با فاصله همینگ مقایسه می‌شود. اگر این مقدار پایین‌تر از آستانه تعیین شده توسط مدیر سیستم باشد، هویت کاربر تایید شده است. به‌طورکلی، بخش اول الگوریتم، شامل ضرب اسکالر با بردارهای orthonormal است که بنا به الزامات عملکرد و آخرین مرحله از الگوریتم برای الزامات غیرقابل انعطاف از الگوریتم BioHashing استفاده می‌شود. همانطور که قبلا ذکر شد، seed تصادفی خواص تنوع و لغوپذیری را تضمین می‌کند.
پروتکل احراز هویت کاربر چندین بار الگوریتم BioHashing را که در بخش بعدی آن را شرح داده‌ایم به کار می‎برد.

۶٫ پروتکل احراز هویت پیشنهادی
پروتکل احراز هویت پیشنهادی از داده‌های بیومتریک استفاده می‌کند که باید از طریق ثبت با دستگاه OffPAD و الگوریتم حفاظت از الگو محافظت شود. طرح‌های حفاظت از الگو بیومتریک یک گروه از فن‌آوری ها هستند، که شامل فن‌آوری‌های قابل ارتقاء حریم خصوصی هستند و برای ارتقاء حریم خصوصی و امنیت اطلاعات بیومتریک مورد استفاده می‌شوند. از این رو، هر روش حفاظت از قالب باید اجازه لغو داده‌های بیومتریک را بدهد و باید با دقت طراحی شده باشد و تجزیه و تحلیل امنیتی قوی داشته باشد. در میان راه‌حل‌های مختلف در کارهای پیشین، حفاظت از الگو می‌تواند با استفاده از رمزنگاری‌های بیومتریک [۱۵]، [۱۴]، [۹]، [۲۰] یا با تبدیل داده‌های ویژگی بیومتریک به دست آید [۲۲]، [۵]، [۲۵]، [۲۳]. همانطور که در بخش بعدی بیان شده، BioHashing یک طرح محبوب است که متعلق به رده دوم است و اجازه لغو یک قالب بیومتریک را می‌دهد.
پروتکل پیشنهادی با اثر انگشت دقیق است اما می‌تواند برای هر روش دیگر بیومتریکی (چهره،…) استفاده شود. هنگامی که از بیومتریک استفاده می‌کنیم، دو مرحله اصلی مورد نیاز است: ثبت‌نام و احراز هویت
۱) ثبت‌نام: این مرحله برای جمع‌آوری قالب مرجع Alice استفاده می‌شود. در طرح پیشنهادی، قالب داده شده توسط یک BioCode با نام Reference Biocode از یک FingerCode (بردار ویژگی محاسبه شده از اثر انگشت) و یک رمز (رمز کاربر با شماره سریال دستگاه OffPAD همراه است) شناخته شده است. رمز کاربر می‌تواند یک رمز عبور یا یک مقدار تصادفی ذخیره شده در دستگاه OffPAD باشد (البته، توسط تایید بیومتریک دستگاه محافظت می‌شود). هنگامی که Reference BioCode محاسبه شده است، به بانک صادرکننده Alice از طریق یک کانال SSL فرستاده می‌شود. بنا به به یک دیدگاه سازمانی، این مرحله می‌تواند در یک شاخه پس از بررسی هویت فیزیکی توسط فرد انجام شود. شکل ۴ پروسه ثبت‌نام را شرح می‌دهد. هیچ حریم خصوصی برای ذخیره Reference BioCode توسط بانک صادرکننده به‌عنوان این الگو قابل لغو و به‌عنوان فرآیند معکوس BioHashing وجود ندارد.
۲) احراز هویت: در طول پرداخت الکترونیکی، بانک صادرکننده باید Alice را تأیید کند (به‌عنوان مثال روند ۳D-Secure). یک چالش به Alice فرستاده می‌شود (شماره نمایش داده شده در کامپیوتر یا شماره‌ای که به طور مستقیم به OffPAD فرستاده می‌شود). Alice مجبور است اثر انگشت و رمز عبور خود را (که توسط بانک صادرکننده شناخته شده نیست) ارائه کند. BioCode ثبت شده FingerCode را در داده‌های بیومتریک، رمز عبور و شماره سریال OffPAD محاسبه می‌کند. چالش ثبت Biocode با استفاده از الگوریتم BioHashing در Capture BioCode با چالش ارسال شده توسط بانک صادرکننده به عنوان رمز محاسبه می‌شود. بانک صادرکننده نیز با استفاده از BioHashing، Biocode مرجع را با به چالش کشیدن الگوریتم در BioCode مرجع محاسبه می‌کند. فاصله همینگ برای مقایسه دو چالش BioCodes استفاده می‌شود و اگر فاصله کمتر از آستانه از پیش تعریف شده باشد، Alice تأیید شده است. شکل ۵ جزئیات کل روند را توضیح می‌دهد.
۳) بحث: چالش ارسال شده توسط بانک صادرکننده اجازه می‌دهد تا یک راه‌حل احراز هویت بیومتریک یک‌باره تعریف کنیم. در این راه‌حل فرض می‌کنیم که OffPAD یک دستگاه امن است. در این راه‌حل، بانک صادرکننده تصمیم‌گیری در مورد احراز هویت Alice را کنترل می‌کند.