<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های houman xl_</title><link>https://virgool.ir/feed/@houmanjudaki</link><description></description><language>fa</language><pubDate>2026-11-12 19:55:23</pubDate><image><url>https://files.virgool.ir/upload/users/927292/avatar/avatar.png</url><title>houman xl_</title><link>https://virgool.ir/@houmanjudaki</link></image><item><title>مکانیزم پرداخت تلفن همراه با ناشناس بودن رایانش ابری</title><link>https://virgool.ir/@houmanjudaki/مکانیزم-پرداخت-تلفن-همراه-با-ناشناس-بودن-رایانش-ابری-pfke0rzxqxbd</link><description>در سالهای اخیر معاملات سنتی با معاملات الکترونیکی جایگزین شده است. برای محافظت از امنیت معاملات الکترونیکی ، سازوکارهای مختلف پرداخت الکترونیکی (پرداخت الکترونیکی) پیشنهاد شده است. با این حال ، در می یابیم که مکانیزم های پرداخت الکترونیکی قبلی شرط عدم انکار در سمت مشتری را تأمین نمی کنند. بنابراین ، یک مشتری مخرب می تواند معامله را به راحتی انکار کند و ممکن است بازرگان پرداختی را دریافت نکند. علاوه بر این ، این مکانیسم ها هزینه های محاسبات و ارتباطات زیادی دارند ، بنابراین نمی توانند برای پرداخت تلفن همراه برای رایانش ابری اعمال شوند. برای حل مشکلات فوق ، ما در این مقاله مکانیسم جدید پرداخت تلفن همراه با ناشناس بودن رایانش ابری را ارائه می دهیم. مکانیسم پیشنهادی نه تنها هزینه محاسبه را کاهش می دهد بلکه نیاز به عدم انکار را در سمت مشتری فراهم می کند. در مقایسه با کارهای مربوطه ، سازوکار پیشنهادی ایمن تر ، منصفانه تر و کارآمدتر است. بنابراین ، سازوکار پرداخت موبایل پیشنهادی مناسب و عملی تر برای رایانش ابری است.کلید واژه ها:  معامله الکترونیکی/  پرداخت موبایل/  پردازش ابریمقدمهبا توسعه سریع فن آوری های شبکه ، معاملات سنتی با معاملات الکترونیکی (معاملات الکترونیکی) در سال های اخیر جایگزین شده اند. در برنامه های معاملات الکترونیکی ، بسیاری از مردم از دستگاه های تلفن همراه برای معامله استفاده می کنند ، که اصطلاحاً تجارت الکترونیکی (تجارت الکترونیکی) نامیده می شود. از آنجا که تجارت الکترونیکی در هر زمان و هر مکان قابل معامله است ، افراد بیشتری از آن برای فروش ، خرید و بازاریابی استفاده می کنند. برای محافظت از امنیت تجارت الکترونیکی ، سازوکارهای مختلف پرداخت الکترونیکی (پرداخت الکترونیکی) ارائه شده است (Abad-Peiro et al.، 1998؛ Chari et al.، 2001؛Kungpisdan et al.، 2003؛ Wei and al. . ، 2005 ؛ Martinez-Pelaez و همکاران ، 2010 ؛ Sun و همکاران ، 2010 ؛ Tsai و همکاران ، 2011). به طور کلی ، یک مکانیزم پرداخت الکترونیکی امن باید محرمانه بودن ، ناشناس بودن ، صداقت ، انصاف و عدم شهرت را فراهم کند. برای تحقق الزامات فوق ، چگونگی طراحی مکانیزم پرداخت الکترونیکی ایمن و عادلانه به مسئله مهمی در تجارت موبایل تبدیل می شود.در سال 2012 ، Isaac and Zeadally (2012) مکانیزم پرداخت ایمن ناشناس را در مدل درگاه پرداخت پرداخت کردند. مشتریان و بازرگان در مکانیسم پرداخت الکترونیکی خود از طریق درگاه پرداخت با یکدیگر ارتباط برقرار می کنند. مشتری به طور مستقیم با تاجر ارتباط برقرار نمی کند ، بنابراین می توان ناشناس بودن مشتری را به دست آورد. علاوه بر این ، آنها از رمزنگاری کلید متقارن استفاده می کنند (Menezes و همکاران1996) برای ارائه محرمانه بودن بنابراین ، اطلاعات پرداخت الکترونیکیمی تواند به خوبی محافظت شود. علاوه بر این ، مکانیسم آنها همچنین با استفاده از کد تأیید پیام (MAC) یکپارچگی را فراهم می کند. بنابراین ، مشتریان و بازرگان می توانند اطمینان حاصل کنند که اطلاعات در هنگام انتقال از طریق شبکه ها دستکاری نمی شودبا توجه به توضیحات فوق ، ایزاک و زدالی از دروازه پرداخت برای محرمانه بودن ، ناشناس ماندن و صداقت استفاده می کنند. در می یابیم که مکانیسم آنها نیازهای رایانش ابری را برآورده می کند زیرا پیام های معاملاتی می توانند در درگاه پرداخت ذخیره و محافظت شوند. یعنی درگاه پرداخت می تواند به عنوان سرور ابری برای پرداخت الکترونیکی در تجارت موبایل اجرا شودبا این حال ، ما همچنین دریافتیم که مکانیزم Isaac and Zeadally انصاف و عدم اعتبار شهرت معاملات الکترونیکی را فراهم نمی کند. در سازوکار خود ، مشتری اطلاعات را به صورت ناشناس برای محافظت از حریم خصوصی پرداخت تولید می کند. این باعث می شود که مشتری بتواند معامله را انکار کند زیرا اطلاعات پرداخت نمی تواند مستقیماً با مشتری ارتباط داشته باشد. علاوه بر این ، مکانیسم آنها از کلید متقارن اضافی بین مشتری و تاجر استفاده می کند. این کلید اضافی ضروری نیست زیرا همه پیام ها باید از طریق درگاه پرداخت منتقل شوند. این امر باعث بروز مشکل اصلی مدیریت مشتری می شود. اگر مشتری بخواهد از بازرگانان اختلاف اقلام خریداری کند ، مشتری باید کلیدهای زیادی را برای بازرگانان مختلف نگه دارد. این همچنین باعث افزایش هزینه های محاسبه و ارتباطات در این سناریو می شود. با توجه به دلایل بالا ، مکانیسم پرداخت الکترونیکی Isaac وZeadally اگر بخواهیم آن را در برنامه های پرداخت تلفن همراه برای رایانش ابری اعمال کنیم ، دارای مشکلاتی است.برای حل مشکلات فوق ، ما در این مقاله مکانیسم جدید پرداخت تلفن همراه با ناشناس بودن رایانش ابری را ارائه می دهیم. مکانیسم پیشنهادی دارای مزایای زیر است. ابتدا مدل پیشنهادی از درگاه پرداخت بین مشتری و بازرگان استفاده می کند و بنابراین مشتری نیازی به ارتباط مستقیم با تاجر ندارد. یعنی مشتری می تواند برای محافظت از حریم خصوصی پرداخت ، ناشناس معامله کند. دوم ، بانک مشتری امضای دیجیتالی را به عنوان اثبات پرداخت تولید می کند. بنابراین ، تاجر می تواند پرداخت را از بانک دریافت کند حتی اگر مشتری مخرب اقدام را انکار کند. سوم ، ما کلیدهای متقارن زائد بین مشتری و بازرگان را حذف می کنیم. مشتری نیازی به نگه داشتن بسیاری از کلیدها برای بازرگانان مختلف ندارد تا مشکل مدیریت کلید حل شود. سرانجام ، ما هزینه های محاسبه و ارتباطات را در سمت کاربر کاهش می دهیم بنابراین مکانیزم پیشنهادی پرداخت تلفن همراه برای محیط های رایانش ابری بسیار مناسب است. با توجه به مزایای فوق ، سازوکار پیشنهادی الزامات امنیتی رازداری ، ناشناس بودن ، صداقت ، انصاف و عدم شهرت را فراهم می کند.سازوکار پیشنهادی ایمن تر از کارهای مربوطه است ، زیرا از دروازه پرداخت به عنوان سرور ابری برای ذخیره اطلاعات پرداخت مشتری استفاده می شود. علاوه بر این ، مکانیسم پیشنهادی منصفانه تر از کارهای مربوطه است زیرا اثبات پرداخت توسط بانک مشتری تولید می شود. بنابراین مشتری نمی تواند معامله را انکار کند. علاوه بر این ، سازوکار پیشنهادی هزینه محاسبه کمتری دارد ، بنابراین برای پرداخت تلفن همراه کارآمدتر است. با توجه به توضیحات فوق ، سازوکار پیشنهادی ایمن تر ، منصفانه تر و کارآمدتر از کارهای مربوطه است. بنابراین ، مکانیسم پیشنهادی پرداخت موبایل برای محیط های رایانش ابری مناسب تر و کاربردی تر است. در این بخش ، مکانیزم پرداخت الکترونیکی Isaac و Zeadally را معرفی می کنیم مکانیسم آنها دارای پنج نقش است: مشتری ، بازرگان ، ناشر (بانک مشتری) ، گیرنده (بانک بازرگان) و درگاه پرداخت. توجه داشته باشیدکه همه پیام های پرداخت در میان مشتری ، بازرگان ، صادر کننده و مالک باید از طریق درگاه پرداخت منتقل شوند. نت های استفاده شده در سازوکار آنها در جدول 1 نشان داده شده است.نشانه های مکانیزم پرداخت الکترونیکی Isaac و Zeadally.مراحل مکانیزم پرداخت الکترونیکی Isaac و Zeadally به شرح زیر شرح داده شده است. مرحله 1: مشتری و بازرگان پیام های لازم را برای شروع سازوکار از طریق درگاه پرداخت با مراحل زیر فرع می کنند.مرحله 1-1: مشتری NID C ، i و TIDReq را به درگاه پرداخت می فرستدمرحله 1-2: درگاه پرداخت پیامهای فوق را به بازرگان ارسال می کندمرحله 1-3: بازرگان ID p و TID رمزگذاری شده توسط آنها را ارسال می کندK SC −M من به درگاه پرداخت.مرحله 1-4: درگاه پرداخت پیام فوق را به مشتری ارسال می کند.مرحله 2: مشتری مراحل زیر را ایجاد می کند:مرحله 2-1: مشتری درخواست کاهش مقدار V SRequest = (MAC ، [(P برنج ، ساعت (OI) ، T S TC ، T C ، تولید می کندI D M) ، K SC-I Z] ، T C ، T S TC).مرحله 2-2: مشتری PRequest = ایجاد می کند { NID C , ID I , Price, OI, z, VSReques  } K SC −M i , and MAC[ OI, P rice, NI DC , I D I , T S TC , z, h(K SC −I Z ), K SC −M i +1 ]مرحله 2-3: مشتری درخواست پرداخت را به درگاه پرداخت می فرستدمرحله 3: درگاه پرداخت به جلو درخواست به تاجرمرحله 4: تاجر با مراحل فرعی زیر VCR درخواست درخواست ادعای ارزش را ایجاد می کندمرحله 4-1: بازرگان برای بدست آوردن OI ، TST C وVSRequest رمزگشایی می کندمرحله 4-2: تاجر اعتبار TST C را تأیید می کند. اگر معتبر باشد ، بازرگانVCRe-quest = (VSRequest، TST M، h (OI)، TID، Price، NID C،ID I ), { VCRe quest, ID M , z, h(KSC −I Z )}KS M−PG k , k , andمرحله 5: دروازه پرداختMAC [(VCRequest ، TST Mand ، z ، happrove (K SC-I Z) را تأیید می کند) ، K PaymentS M − P G k + 1]. با استفاده از شبکه خصوصی بانکها با مراحل زیرمرحله 5-1: درگاه پرداختVCRequest را رمزگشایی می کند و اعتبار TST M را بررسی می کند. در صورت معتبر بودن ، گیت راه NID C ، ID M ، VSRequest ، TID ، h (OI) ، z ، Price و h (K SC-I Z) را به صادرکننده ارسال می کند. علاوه بر این ، درگاه Price و ID M را برای خریدار ارسال می کند.مرحله 5-2: صادر کننده اعتبار مشتری را با پیام های درگاه پرداخت بررسی می کند. اگر مشتری معتبر باشد ، صادر کننده معامله را تأیید می کندمرحله 5-3: خریدار قیمت و شناسه M را بررسی می کند و از صادرکننده می خواهد پول را به حساب بازرگان منتقل کند. مرحله 5-4: صادر کننده V SResponse = تولید می کند{St t، h (OI)، h (K S M − P G k +1)} K SC −I Z و می فرستدV SResponse ، St t ، h (St t ، h (OI)) ، h (K SC −I Z) به درگاه پرداخت.مرحله 6: درگاه پرداخت V CResponse = ایجاد می کند{St t، h (St t، h (OI)، h (K SC −I Z))} K S M − P G k +1 و آن را برای تاجر می فرستد.مرحله 7: درگاه پرداخت با مراحل فرعی زیر پاسخ پرداخت را ایجاد می کند.مرحله 7-1: درگاه پرداخت باعث ایجاد پاسخ P = می شودS tep 7-2: مشتری PResponse را رمزگشایی می کند تا h (OI) را بدست آورد. سپس ، مشتری بررسی می کند که آیا h (OI) دریافتی برابر با h (OI) خودش باشد. اگر برابر نباشند ، مشتری پیام خرابی را به درگاه پرداخت می فرستد. سپس ، درگاه پرداخت روش بازیابی را شروع می کند یا پیام را دوباره ارسال می کند.مراحل مکانیزم ایزاک و زایدالی در شکل 1 نشان داده شده است. با توجه به توضیحات فوق ، در می یابیم که مکانیسم آنها اشکالات زیر را دارد. اول ، مشتری و تاجر دارای یک کلید متقارن K SC −M i هستند ، بنابراین درخواست پرداخت درخواست نیز می تواند توسط بازرگان ایجاد شود. بنابراین مشتری می تواند ادعا کند که درخواست توسط وی تولید نشده و معامله را انکار می کند. دوم ، مکانیسم آنها از چهار کلید تقارن K SC −M i ، K SC −I Z ، K SC −P G j و K S M − P G k استفاده می کند. با این حال ، در می یابیم که K SC −M i غیرضروری است زیرا تمام پیام های بین مشتری و بازرگان باید از طریق درگاه پرداخت منتقل شود. اگر مشتری بخواهد با چندین تاجر معامله کند ، مشتری باید بسیاری از کلیدهای متقارن را برای بازرگانان مختلف حفظ کند. یعنی استفاده از K SC −M i مشکل مدیریت کلیدی را برای مشتری ایجاد می کند. علاوه بر این ، این امر همچنین هزینه های محاسبه و ارتباطات را برای مشتری افزایش می دهد. بنابراین ، سازوکار آنها برای پرداخت تلفن همراه در برنامه های رایانش ابری مناسب نیست.1. 2. بررسی کار مربوطه مکانیسم پیشنهادی پرداخت موبایل برای رایانش ابریبرای حل اشکالات مکانیزم Isaac و Zeadally ، ما در این بخش مکانیسم جدید پرداخت تلفن همراه با ناشناس بودن رایانش ابری را ارائه می دهیم. سازوکار پیشنهادی دارای پنج مشارکت کننده است: مشتری ، بازرگان ، صادر کننده ، تملک کننده و دروازه پرداخت در منطقه ابر. توجه داشته باشید که صادر کننده بانک مشتری است که مسئولیت صدور کارت اعتباری برای مشتری را دارد. علاوه بر این ، متصرف بانک بازرگان است که وظیفه دریافت پول از ناشر را بر عهده دارد. علاوه بر این ، آن را به دو مرحله تقسیم می شود: مرحله اولیه و مرحله معامله.شکل 2. مدل مکانیسم پیشنهادی پرداخت موبایل.سازوکار پیشنهادی در شکل 2 نشان داده شده است. نت های استفاده شده در سازوکار پیشنهادی در جدول 2 نشان داده شده است.3.1. The initialization phaseدر این مرحله ، مشتری ، بازرگان ، صادر کننده و متعهد باید در درگاه پرداخت ثبت نام کنند تا کلیدهای جلسه K SC −P G a ، K S M − P G y ، و K SC آن را بدست آورند. سپس ، صادرکننده پارامترهای e ، n و d مورد استفاده در رمزنگاری RSA را تولید می کند (Rivest و همکاران ، 1978) ، جایی که (e ، n) جفت کلید عمومی است و d کلید خصوصی است. توجه داشته باشید که جفت کلید عمومی توسط یک مرجع صدور گواهینامه تأیید شده است.جدول 2نت های استفاده شده در سازوکار پیشنهادی.3.2 مرحله معاملهمرحله 1: مشتری اطلاعات خرید A را تولید می کند و درخواست خرید را به بازرگان می فرستد تا معاملات را با مراحل زیر فرعی آغاز کند.مرحله 1-1: مشتری NID C و A را به درگاه پرداخت می فرستد. سپس ، درگاه پرداخت NID C و A را به بازرگان منتقل می کند.مرحله 1-2: پس از دریافت NID C و A ، TInfo را تولید کرده و به درگاه پرداخت می فرستد. سپس ، درگاه پرداخت TInfo را به مشتری منتقل می کند. سرانجام ، تاجر NID C و A را در پایگاه داده خود ثبت می کند.مرحله 2: مشتری از صادرکننده می خواهد تا با پرداخت مراحل زیر ، اطلاعات پرداخت را به عنوان بدهی پرداخت امضا کند.مرحله 2-1: درخواست مشتری مشتری = (h(T Info) , I DC , NI DC , h(m), P rice, T SC )K SC −It .مرحله 2-2: مشتری درخواست را به درگاه پرداخت ارسال می کند. سپس ، درگاه پرداخت آن را به صادرکننده منتقل می کند.مرحله 2-3: صادرکنندهSRequest را رمزگشایی می کند و بررسی می کند TS C یک مهر زمان معتبر است یا نه. سپس ، صادرکننده با استفاده از کلید خصوصی d خود S = h (m) d mod n را به عنوان یک امضای دیجیتالی محاسبه می کند. سپس ، صادر کننده ID C ، NID C ، h (TInfo) و S را در پایگاه داده خود ثبت می کند. سپس ، آن را ارسال می کند(S) K SC این از طریق درگاه پرداخت به مشتری می رسد.مرحله 2-4: مشتری با بررسی اینکه h (m) برابر است با S e mod n ، صحت S را تأیید می کند. اگر آنها برابر باشند ، مشتری این امضا را به عنوان اثبات پرداخت می پذیرد.مرحله 3: مشتری (S، m، h (T Info)، T SC، I ssuer _I D) K SC −P G a را به درگاه پرداخت می فرستد. سپس ، درگاه پرداخت پیام فوق را رمزگشایی می کند تا S ، m ، h (TInfo) ، TS C ، و Issuer _ ID دریافت کند. سپس ، درگاه پرداخت ایجاد می شود(S، m، h (T Info)، T SC، I ssuer _I D) K S M − P G y و آن را برای تاجر می فرستد.مرحله 4: تاجر رمزگشایی می کند (S ، m ، h (T Info) ، T SC ، I ssuer _I D) K S M − P G y و با مقایسه با زمان فعلی T ، اعتبار TS C را بررسی می کند. اگر (T - TS C) در یک بازه زمانی معتبر باشد ، بازرگان اطمینان حاصل می کند که (S، m، h (T Info)، T SC، I ssuer _I D) KSM − PG y توسط دروازه ارسال می شود نه یک مهاجم . سپس ، تاجر S را با استفاده از کلید عمومی صادر کننده تأیید می کند و بررسی می کند که آیا m دارای NID C و A صحیح باشد. اگر تأیید فوق صحیح باشد ، بازرگان تولید می کند (S, m, h(T Info) , I D M , T S M , P rice, I ssuer _I D, Acquirer _I D) K S M−P G y and sends it to the payment gateway.مرحله 5: درگاه پرداخت پیام فوق را رمزگشایی و ارسال می کند(S، NID C، ID M، h (TInfo)، Price، Acquirer _ ID) به ناشر با استفاده از شبکه خصوصی بانک ها. علاوه بر این ، درگاه پرداخت (h (TInfo) ، Price ، ID M ، Issuer _ ID) را نیز به درخواست کننده ارسال می کند.مرحله ششم: صادر کننده معامله را تأیید و تأیید می کند. سپس ، متقاضی با اقدامات فرعی زیر پول را به حساب بازرگان در گیرنده منتقل می کند.مرحله 6-1: صادر کننده اعتبار S را تأیید می کند و از NID C برای بدست آوردن شناسه C واقعی در پایگاه داده خود استفاده می کند. سپس ، صادر کننده بررسی می کند که آیا اعتبار مشتری برای پرداخت مبلغ قیمت کافی است. اگر تأییدهای فوق صحیح باشد ، ناشر پول را به حساب بازرگان در مالک انتقال می دهد. سرانجام ، صادر کننده PResponse و h (TInfo) را به درگاه پرداخت می فرستد.مرحله 6-2: پس از دریافت پول ، مالک بررسی می کند که آیا مقدار پول صحیح است. اگر صحیح باشد ، خریدار Stt و h (TInfo) را به درگاه پرداخت می فرستد.مرحله 7: درگاه پرداخت به ترتیب(PResponse ، h (TInfo)) و (Stt، h (TInfo)) را به مشتری و بازرگان ارسال می کند. سرانجام ، مشتری و بازرگان هم می توانند نتیجه معامله را بررسی کنند.شکل 3مراحل فوق سازوکار پیشنهادی را نشان می دهد. مطابق مراحل فوق ، سازوکار پیشنهادی از مزایای زیر برخوردار است. اول ، مشتری از شناسه ناشناس NID C برای تولید اطلاعات پرداخت استفاده می کند. بنابراین ، تاجر نمی داند چه کسی کالا را خریداری می کند. علاوه بر این ، صادر کننده نمی داند مشتری چه چیزی را خریداری می کند زیرا TInfo و m توسط عملکرد هش یک طرفه محافظت می شوند. یعنی مشتری که حریم خصوصی را خریداری می کند می تواند به خوبی محافظت شود. دوم ، بانک مشتری امضای S را به عنوان اثبات پرداخت تولید می کند. بنابراین ، حتی اگر مشتری مخرب معامله را انکار کند ، بازرگان می تواند با استفاده از S پرداخت را از صادر کننده دریافت کند. سوم ، مشتری در مکانیزم پیشنهادی نیازی به نگه داشتن کلید جلسه بین مشتری و تاجر ندارد. بنابراین ، اگر مشتری بخواهد با بازرگانان مختلف معامله کند ، بسیاری از کلیدهای جلسه را نگهداری نمی کند. در مقایسه با مکانیزم ایزاک و Zeadally ، مکانیسم پیشنهادی دارای کلیدهای جلسه کمتری است بنابراین می توان هزینه های محاسبه و ارتباطات را نیز کاهش داد. بنابراین ، سازوکار پرداخت موبایل پیشنهادی برای محیط های رایانش ابری بسیار مناسب است.در این بخش ، ما حملات احتمالی را برای تجزیه و تحلیل امنیت مکانیسم پیشنهادی انجام می دهیم. تجزیه و تحلیل دقیق به شرح زیر شرح داده شده است.4.1 حمله خارجیفرض کنید که یک مهاجم می خواهد اطلاعات پرداخت را از SRequest = (h (T Info) ، I DC ، NI DC ، h (m) ، P برنج ، T SC) K SC tآن ، سپس سعی می کند که رمزگشایی SRequest. با این حال ، این حمله غیرممکن است زیرا مهاجم کلید جلسه K SC را نمی داند. بدون دانستن کلید جلسه ، مهاجم نمی تواند رمزگذاری متقارن را بشکند (Menezes و همکاران ، 1996). به طور خلاصه ، غیرممکن است که یک مهاجم بخواهد اطلاعات را از (S، m، h (T Info)، T SC، I ssuer _I D) K SC −PG a و (S، m، h) بدست آورد. (T Info) ، T SC ، I ssuer _I D) KSM − PG y. بنابراین ، حمله بیرونی برای سازوکار پیشنهادی غیرقابل اجرا است.4.2 حمله خودیفرض کنید که صادر کننده می خواهد بداند مشتری از چه چیزی خریداری می کندSRequest = (ساعت (T اطلاعات) ، I DC ، NI DC ، ساعت (متر) ، P برنج ، T SC) K SC tاین. با این حال ، غیرممکن است زیرا اطلاعات پرداخت m توسط یک عملکرد هش یک طرفه محافظت می شود. بنابراین ، صادر کننده نمی تواند بداند مشتری چه چیزی خریداری می کند تا از حریم خصوصی خرید محافظت شود.4.3 حمله مجددفرض کنید که یک مهاجم ارتباط بین مشتری و درگاه پرداخت را برای دریافت استراق سمع می کند(S، m، h (T Info)، T SC، I ssuer _I D) K SC −P G a. سپس ، مهاجم دوباره پیام را به درگاه پرداخت می فرستد و سعی می کند با تاجر معامله کند. با این حال ، این حمله غیرقابل اجرا است زیرا(S، m، h (T Info)، T SC، I ssuer _I D) K SC −P G a حاوی مهر زمان TS C است که زمان واقعی خرید مشتری را نشان می دهد. درگاه پرداخت می تواند از طریق ارسال زمان سنج و پیام دریافتی T از پیام توسط مهاجم ارسال شود. اگر (T - TS C) بزرگتر از یک بازه زمانی معقول باشد ، بازرگان در می یابد که پیام توسط مهاجم ارسال می شود. بنابراین ، مکانیسم پیشنهادی می تواند از حمله مجدد جلوگیری کند.Table 34.4 بی هویتی و هزینه های مضاعفمکانیسم پیشنهادی ناشناس بودن را فراهم می کند زیرا تمام مراحل معامله با استفاده از شناسه ناشناس مشتری NID C طراحی می شود. بنابراین مشتری می تواند به صورت آنونی با معامله گر معامله کند.از طرف دیگر ، سازوکار پیشنهادی می تواند از هزینه های مضاعف جلوگیری کند زیرا اطلاعات پرداخت m حاوی TInfo است که زمان معامله ، تاریخ و شماره سریال را نشان می دهد. اگر یک مشتری مخرب بخواهد از S و m قدیمی برای معامله دوباره استفاده کند ، بازرگان می تواند با بررسی TInfo در پایگاه داده خود ، رفتار دو برابر را کشف کند.4.5 عدم انکارفرض کنید مشتری بدخواه معامله قانونی را که انجام داده است انکار کند. در این حالت ، تاجر می تواند از S به عنوان مدرک پرداخت استفاده کند زیرا S توسط صادرکننده امضا شده است. پس از تأیید S ، صادر کننده پول را به حساب بازرگان منتقل می کند حتی اگر مشتری این معامله را انکار کند. بنابراین ، سازوکار پیشنهادی نیازهای امنیتی عدم انکار را فراهم می کند.ما هزینه های محاسبه Isaac and Zeadally (2012) ، Pourghomi و همکاران را تحلیل می کنیم. (2014) و سازوکار ما در جدول 3.نمادهای Sym و Hash به ترتیب رمزگذاری / رمزگشایی متقارن و محاسبات عملکرد هش یك طرفه هستند. طبق جدول 3 ، هزینه محاسبه مکانیزم پیشنهادی کمتر از هزینه های Isaac and Zeadally (2012) و Pourghomi و همکاران است. (2014) بنابراین ، سازوکار پیشنهادی مناسب و عملی تر برای پرداخت تلفن همراه در رایانش ابری است.3. تحلیل و بحث و گفتگونتیجه گیریدر این مقاله ، ما مکانیزم پرداخت جدید تلفن همراه با ناشناس بودن محاسبات ابری را ارائه داده ایم. مکانیسم پیشنهادی الزامات امنیتی رازداری ، ناشناس بودن ، صداقت ، انصاف و عدم شهرت را ارائه می دهد. در مقایسه با کارهای مربوطه ، سازوکار پرداخت الکترونیکی پیشنهادی هزینه محاسبات و ارتباطات کمتری دارد. بنابراین ، سازوکار پرداخت موبایل پیشنهادی بسیار کارآمد و مناسب برای کاربردهای رایانش ابری است.</description><category>houman xl_</category><author>houman xl_</author><pubDate>Mon, 31 May 2021 15:36:45 +0430</pubDate></item><item><title>مکانیزم پرداخت تلفن همراه با ناشناس بودن رایانش ابری</title><link>https://virgool.ir/@houmanjudaki/مکانیزم-پرداخت-تلفن-همراه-با-ناشناس-بودن-رایانش-ابری-j9px4znwnxvj</link><description>لینک دانلودhttps://s19.picofile.com/d/8434612884/b585e553-1a7c-4b18-a136-6f74704cdb20/%DB%8C%DA%A9_%D9%85%DA%A9%D8%A7%D9%86%DB%8C%D8%B2%D9%85_%D9%BE%D8%B1%D8%AF%D8%A7%D8%AE%D8%AA_%D9%87%D9%85%D8%B1%D8%A7%D9%87_%D9%86%D8%A7%D8%B4%D9%86%D8%A7%D8%B3%DB%8C_%D8%AF%D8%B1_%D8%B1%D8%A7%DB%8C%D8%A7%D9%86%D8%B4_%D8%A7%D8%A8%D8%B1%DB%8C.docx</description><category>houman xl_</category><author>houman xl_</author><pubDate>Sun, 30 May 2021 19:48:20 +0430</pubDate></item></channel></rss>