امنیت سیستم‌های بانکداری الکترونیکی امروزی
تکفا- امروزه فناوری رشد و تکاملی شتابان دارد و همواره ابعادی تازه را در زندگی روزانه ما پدید می‌آورد و در این راه، سیستم‌های بانکداری الکترونیکی، خدمات بانکی آسانی را برای ما فراهم آورده است.
تبادل اطلاعات میان کاربر و بانک، به‌کمک ابزارهای ATM1، بانکداری تلفنی و اینترنتی و بیش از همه بانکداری موبایلی، تا اندازه زیادی بهبود یافته است.
این نوشتار به امنیت سیستم‌های بانکداری الکترونیکی می‌پردازد و تمرکز آن بر بانکداری اینترنتی و موبایلی بوده، تکنیک‌هایی که در این زمینه در سیستم‌های جاری به‌کار می‌رود را ارایه می‌کند تا یک الگو و سرمشق را - به‌همراه بهبود و توسعه در آینده - نشان می‌دهد. بیشتر مواردی که در این نوشتار می‌آیند، در دیگر خدمات الکترونیکی - مانند تجارت الکترونیکی و دولت الکترونیکی - نیز کاربرد دارند.
1- پیش‌گفتار
سیستم‌های بانکداری الکترونیکی به همه این امکان را می‌دهد که سریع و آسان به کارهای بانکی خود - مانند دریافت موجودی حساب، انتقال پول میان حساب‌های گوناگون یک مشتری، انتقال پول از حساب یک مشتری به حساب مشتری دیگر و دریافت صورت حساب بانکی در یک دوره ویژه - دسترسی داشته باشند. برخی از بانک‌ها خدماتی مانند انتقال سهام و ارسال فایل‌های پرداخت از یک حساب مشخص به حساب افراد گوناگون (مانند پرداخت حقوق) را نیز انجام می‌دهند.
با گسترش فناوری، انواع سیستم‌های بانکداری الکترونیکی نیز ایجاد شده است که هر یک از آنها ابعادی تازه را - در زمینه تبادل اطلاعات میان کاربر و بانک - ارایه می‌کنند. ATM نخستین سیستم شناخته شده‌ای است که برای آسانی دسترسی کاربران به فعالیت‌های بانکی خود معرفی گردید. به‌کمک یک رابط گرافیکی کاربر (UGI2)، کاربر می‌تواند برخی از این کارها را اجرا کند و این عملیات به سیستم کامپیوتر مرکزی بانک منتقل می‌گردد. گام بعدی، معرفی بانکداری تلفنی بود. کاربران با تلفن از خانه به سیستم کامپیوتری بانک متصل شده، با کلیدهای تلفن کار بانکی خود را انجام می‌دادند.
اینترنت نیز یک جایگزین تازه برای سیستم بانک تلفنی پیشنهاد کرده است. مردم با یک رابط کاربرپسند و پیچیده‌تر، یک مرورگر یا برنامه کاربردی استاندارد، می‌توانند در اینترنت به سیستم کامپیوتری بانک راه یابند. ابزارهای الکترونیکی همواره در حال کوچک شدن هستند، در حالی‌که کارایی آنها افزایش می‌یابد. هم‌اکنون، تلفن همراه نیز امکان اجرای سیستم بانکداری الکترونیکی را فراهم آورده است.
1-1- دامنه پژوهش
این نوشتار درباره امنیت سیستم‌های بانکداری الکترونیکی امروزی سخن می‌گوید و تمرکز آن، بیشتر روی بانکداری اینترنتی، www ]2[ و بانکداری موبایلی ]32[، 3WAP است. کار ما برپایه یک بررسی گسترده از سیستم‌های موجود بانکداری اینترنتی جهانی است و این بررسی بر مبنای اطلاعات عمومی موجود تنظیم گردیده است. بررسی و پژوهش نیز روی کاربر و تبادل اطلاعات میان کاربر و بانک متمرکز است.
ما امنیت نزدیک به 30 سیستم بانکداری الکترونیکی را بررسی کرده‌ایم که تنها بخش کوچکی از سیستم‌های زیر پوشش بانکداری الکترونیکی است و معتقدیم که این زیرمجموعه، نماینده خوبی برای همه سیستم‌های بانکی موجود است.
1-2- عنوان بخش‌های این نوشتار
این نوشتار به‌صورت زیر سازماندهی شده است: بخش 2 با توضیح زیربنای معماری www و سیستم‌های بانکداری الکترونیکی WAP آغاز می‌شود، سپس نیازهای اساسی امنیت در سیستم بانکداری الکترونیکی تعیین می‌گردد، تعادل مهم امنیت در برابر هزینه نشان داده می‌شود، خدمات متفاوت بانک در سیستم بانکداری الکترونیکی - که با ساختار درونی بانک مرتبط است - به‌کوتاهی بررسی می‌شود و سرانجام فرق میان دو سیستم امنیت شناخته می‌شود.
بخش 3 به امنیت مخابرات میان مشتری و بانک می‌پردازد و بخش 4 موضوع احراز هویت مشتری را به‌دقت تشریح می‌کند. در بخش 5 نیز جنبه‌های دیگر امنیت بررسی می‌شود و در پایان در بخش 6، دست‌آوردها جمع‌بندی خواهد شد. این مطالب اشاره‌ای به بهترین روش کنونی و چند پیشنهاد برای بهبود در آینده را نیز در بر دارد.
2- معماری و نیازمندی‌های امنیت
2-1- معماری اینترنت
شکل 1 ساختار معماری در سیستم بانکداری الکترونیکی مبتنی بر اینترنت
پرکاربردترین راه ارتباط با بانک - برای کاربری که یک کامپیوتر شخصی با اتصال شبکه دارد - از طریق یک مرورگر وب4 برای کار بانکی بر بستر شبکه جهانی (WWW5) یا بانکداری اینترنتی6 (وبی) است. در این حالت پروتکل استاندارد برای ارتباط میان مرورگر و وب‌سرور7 بانک به‌کار خواهد رفت. این پروتکل استاندارد http است که بالای لایه امنیت جای دارد. http زبان ارتباطی شبکه جهانی است.
یک بانک اغلب به امنیتی بیش از آنچه که مرورگرهای معمولی فراهم می‌آورند، نیاز دارد. اعمال این امنیت اضافه در محدودیت‌های آمریکا برای صادرات، ، به‌ویژه شامل رمزنگاری نیرومند است. یک برنامه کاربردی ویژه کلاینت / سرور8 قابل نصب بر کامپیوترهای شخصی، ارتباط با بانک را برقرار می‌کند. پروتکل مشابهی که در مرورگر/سرور وب به‌کار می‌رود، امنیت دلخواه را فراهم می‌آورد. اما بانک باید نرم‌افزار مورد نیاز مشتری را فراهم کند، زیرا به مرورگرهای نصب شده روی کامپیوتر مشتری اعتماد چندانی نیست.
برای دوری از مسایل مرتبط به توزیع و نصب نرم‌افزارهای اضافه کامپیوتر مشتری، بانک اغلب یک راه‌حل مناسب را پیش می‌گیرد. یک مرورگر عادی روی کامپیوتر مشتری نصب می‌گردد، اما برای افزایش ضریب امنیت دلخواه، یک قطعه برنامه جاوا9 از سایت بانک روی کامپیوتر مشتری کپی می‌شود. این برنامه یک نرم‌افزار کوچک است که در هنگام فعال شدن مرورگر، به‌کار افتاده، امنیت دلخواه را تامین می‌کند.
بزرگترین امتیاز این روش این است که سرور بانک می‌تواند نرم‌افزار مشتری را پشتیبانی و روزآمد کند. کامپیوتر مشتری به‌طور خودکار نگارش‌های تازه نرم‌افزار را از سایت بانک دریافت می‌شود. لذا بانک‌ها نیازی به توزیع و نصب نرم‌افزار خود با روش‌های پیشین ندارند.
2-2- معماری WAP
شکل 2) زیربنای معماری سیستم بانکداری الکترونیکی بر مبنای WAP
هنگامی‌که یک مشتری، موبایل با امکانات WAP داشته باشد، می‌تواند با ارتباط بی‌سیم به بانک متصل شود. WAP در اصل یک ابزار بدون سیم برای استفاده از پروتکل اینترنتی یعنی TCP/IP است.
برای اتصال بی‌سیم به اینترنت، به پراکسی WAP یا گیت‌وی10 نیاز است تا پروتکل WAP را به پروتکل TCP/IP ترجمه و تبدیل کند. برای مثال این نرم‌افزار با کدگذاری، حجم داده‌ها را برای ارسال کاهش می‌دهد.
همچون www، رابط کاربر سیستم بانکداری الکترونیکی، یک مرورگر کوچک در تلفن همراه است.
ارتباط میان تلفن همراه و پراکسیWAP11 با پروتکلی - که با آنچه که در اینترنت به‌کار می‌رود، بسیار همانند است - محافظت می‌شود.
اختلاف عمده در سیستم بانکداری بر مبنای WAP، این است که ارتباط نقطه‌به‌نقطه میان کامپیوتر مشتری و وب‌سرور بانک وجود ندارد. بانک نباید متکی بر نرم‌افزار پیش‌فرض و غیرقابل اعتماد باشد، اما در یک محیط با سرور ایمن و قابل اعتماد، می‌تواند کار کند.
2-3- نیازمندی‌های امنیت
نیازمندی‌های امنیتی عمومی زیر ]22[در سیستم‌های بانکداری الکترونیکی نیز به‌کار می‌رود:
* امنیت و رازداری12، این اطمینان را می‌دهد که تنها افراد صلاحیت‌دار می‌توانند به محتوای اطلاعات مبادله شده دست یابند. برای مثال، استراق‌سمع‌کنندگان نباید بفهمند که یک کاربر خاص چه اعمالی در سیستم انجام می‌دهد.
* تایید داده‌ها13، یعنی تایید داده‌های اصلی و حفظ یکپارچگی داده و اینکه داده‌ها از دستکاری و تغییر توسط افراد غیرمجاز مصون باشد. دستکاری وارده شامل افزودن، حذف یا تغییر محتوای داده است. برای مثال، کاربر و بانک باید اطمینان یابد که داده موجود واقعی است نه داده دستکاری شده.
* تایید موجودیت14، کاربر باید - پیش از آن‌که اطلاعات حساسی را بفرستد - اصمینان یابد که با بانک حقیقی کار می‌کنند. بانک نیز باید پیش از اجرای تراکنش‌ها، کاربر را شناسایی کند.
* انکار ناپذیری15، از تکذیب عملیات انجام شده پیشین جلوگیری می‌کند. برای نمونه، بانک باید بتواند ثابت کند که یک کاربر خاص، کارهی ویژه‌ای را انجام داده است، اما به‌هر حال آن‌را فراموش یا تکذیب می‌کند.
2-4- هزینه در ازای امنیت
اندازه امنیت، نیازمند این است که از برخی ریسک‌ها و به‌بار آوردن هزینه‌های مربوط به آن جلوگیری کند. درجه و مقیاس امنیت نیز، خود هزینه‌هایی را به سیستم تحمیل می‌کند. اینکه سیستم دارای امنیت بالا باشد، هزینه‌های خود را خواهد داشت و بانک در این باره تصمیم خواهد گرفت.
در سیستم‌های بانکداری الکترونیکی، باید تا جای ممکن، هزینه‌های اضافی مربوط به مشتری کاهش یابد و کاربر بتواند از سیستم بانکداری الکترونیکی و نرم‌افزارهای استاندارد موجود بهره برد. این کار سیستم بانکداری الکترونیکی را جذاب‌تر خواهد کرد، اما متاسفانه ممکن است امنیت سیستم را به مخاطره اندازد. در عمل بانک‌ها تلاش می‌کنند که با امکانات بیشتر برای کاربران، درجه ریسک سیستم را نیز به کمترین اندازه برسانند.
2-5- خدمات سیستم بانکداری الکترونیکی
این مقاله تمرکز خود را بر کاربر و تبادل اطلاعات میان کاربر و بانک قرار داده است؛ با این وجود اگر اندکی به ساختار درونی بانک پرداخته شود، بینش و آگاهی بیشتری در سیستم بانکداری الکترونیکی ایجاد خواهد شد.
اگر بخواهیم یک سیستم بانکداری الکترونیکی دلخواه را بررسی کنیم، چهار وظیفه عمده در آن بانک موجود است. این چهار وظیفه، چهار گونه خدمت را ارایه می‌کنند:
1) بانک - برای مبادله اطلاعات با مشتریان - نیاز به یک رابط سرور16 دارد. به‌این رابط در همه محیط‌های WWW, ATM و WAP نیاز است.
2) بانک باید هویت و اطلاعات مشتری را و درستی پاسخ‌های او را بررسی کند. این کار توسط سرور تایید17 انجام می‌پذیرد.
3) عملیات مالی توسط سرور تراکنش18 ارزیابی می‌شود. این سرور یک رابط ساده میان کاربر و بانک را نیز فراهم می‌آورد.
4) سرانجام کامپیوتر بزرگ19 تراکنشی را انجام داده، پیشینه مالی مورد نیاز را نگهداری می‌کند.
این ساختار به خدمات گوناگونی که در هر سیستم بانکداری الکترونیکی وجود دارد، بازمی‌گردد.
امنیت مخابراتی میان کاربر و بانک به‌کمک بخش سرور رابط و احراز هویت وی نیز توسط سرور تایید انجام می‌پذیرد.
باید توجه شود که ممکن است که این کار به شخص ثالث - مانند مایکروسافت پاسپورت20 - متکی باشد]28[ که یک کد شناسایی به کاربر اختصاص می‌دهد تا بتواند همه کارهای آنلاین خود را انجام دهد. گرچه این اعتبارسنجی ممکن است برای برخی از فعالیت‌ها - مانند دادوستدهای الکترونیکی - کارساز باشد، اما احراز هویت در سیستم‌های بانکداری الکترونیکی بسیار مهم‌تر و فراتر از آن است که به این سیستم‌ها اعتماد شود.
3- امنیت مخابرات میان کاربر و بانک
در این بخش، کار تنها به راه‌حل‌های استانداردی - یعنی SSL/TLS برای اینترنت و WTLS برای تلفن همراه - محدود می‌شود که در بیشتر سیستم‌های بانکداری الکترونیکی به‌کار می‌رود.
3-1- SSL/TLS/WTLS
SSL 21 نخستین بار به ابتکار نت‌اسکیپ22 به‌وجود آمد. SSL توسط IETF برای پروتکل امنیتی لایه انتقال داده ((TLS23 پذیرفته است. جامعه WAP پروتکل TLS ]4[ را برای تولید تجهیزات بی‌سیم (WTLS24) ]33[ پذیرفت. اگرچه اختلافاتی اندک میان این پروتکل‌ها وجود دارد، اما در اصل همه آنها یک سرویس امنیتی را فراهم می‌آورند و آن ایجاد کانال ارتباطی ایمن میان کاربر و بانک است.
3-1-1- کانال ایمن25
پروتکل SSL/TLS/WTLS یک کانال ارتباطی ایمن را میان کاربر و بانک فراهم می‌آورد. این بدان معنی است که داده انتقال یافته از یک سو به سوی دیگر، کاملا امن و درست خواهد بود (امنیت) و از تداخل اطلاعات و دستکاری آن توسط دیگران جلوگیری می‌کند (تایید داده‌ها).
بانک همیشه احراز هویت می‌کند و کاربر هم نیاز به شناسایی دارد. توجه داشته باشید که بسیاری از سیستم‌های بانکداری الکترونیکی به خصوصیات کانال امنیتی اعتبارسنجی (تشخیص هویت) مشتریان متکی نیستند، بلکه مکانیزم تشخیص هویت مشتری را در بالای این کانال امنیتی قرار می‌دهند.
دست‌آورد پروتکل SSL/TLS/WTLS این است که به‌سادگی پروتکل‌های ارتباطی دیگر - مانند http - را نیز به‌کار می‌گیرد. این پروتکل‌ها تنها یک کانال امن فراهم می‌کنند، اما امکان عدم انکار را فراهم نمی‌آورند.
در طرف گیرنده، داده فرستاده شده، کانال امن را ترک می‌کند و حفاظ رمزنگاری از گردونه خارج می‌شود و هیچ امضای دیجیتالی نیز در طرف داده کاربر وجود ندارد. بنابراین سیستم بانکداری الکترونیکی باید مکانیزم " انکار ناپذیری" را در بالای کانال امنیتی خود جای دهد، هرچند که در عمل چنین نمی‌کنند.
3-1-2- توافق و انتقال داده 26
ارتباط میان کاربر و بانک به دو بخش توافق و انتقال داده تقسیم می‌شود. منظور از "توافق" سه چیز است: نخست کاربر و بانک می‌پذیرند که یک سری الگوریتم رمزنگاری را برای انتقال داده و شناسایی دو طرف و به‌کار برند و کلیدهای رمزنگاری را نیز می‌پذیرند. دوم، آنها نیاز دارند که یک سری کلیدهای رمزنگاری برای حفاظت از داده‌ها به‌وجود آورند و سوم، بانک کاربر را تایید و تصدیق می‌کند و ممکن است که کاربر هم بانک را تایید کند.
وقتی‌که کار توافق پایان یابد، داده می‌تواند جابه‌جا شود. داده‌ها به بسته‌هایی کوچک تقسیم شده و به‌صورت رکوردهای حفاظت‌شده فرستاده می‌شود. برای تامین یکپارچگی داده، یک کد تایید پیام (MAC27) بر هر بسته داده محاسبه و نشانیده می‌شود و سرانجام، بسته‌ها و MAC رمزگشایی می‌گردند.
3-2- SSLV2/SSLV3/TLS
نخستین نسخه عمومی SSL (نگارش 2) دارای عیب‌ها و کاستی‌های امنیتی بود که در نگارش 3 برطرف گردید. از آنجا که امروزه مرورگرها هنوز از نگارش 2 پشتیبانی می‌کنند، در این بخش به‌کوتاهی، مشکلات امنیتی ]25[ آن برشمرده می‌شود.
SSL برای رمزگذاری و رمزگشایی کلیدهای رمزنگاری همانندی را به‌کار می‌برد. این بدان معنا است که در حالت خروجی، از امنیت MAC کاسته می‌شود.
نگارش 2 یک ساختار MAC ضعیف دارد و سراسر متکی به توابع رمزکننده MD5 ]6[ است که توسط دوبرتین28 توسعه یافته است. نگارش دوم SSL هیچ‌گونه حفاظتی برای "توافق" ندارد. بنابراین ممکن است داده ارسالی مورد هجوم و دستبرد قرار گیرد و ارسال داده قطع گردد و سرانجام، روشن نیست که آیا داده به‌طور کامل ارسال شده است یا نه؟
گروه کاری "IETF TLS" نگارش 3 SSL را - که برای بالابردن امنیت تغییراتی اندک را در نگارش 2 داده - پذیرفته است.
3-3- WTLS
جامعه WAP پروتکل TLS - که مناسب محیط بی‌سیم با دستگاه‌های کوچک است و محدودیت در پهنای باند، حافظه و پردازش دارد- را پذیرفته است. WTLS کاربرد رمزنگار بیضی‌شکل (پردازش و حافظه محدود) را به‌صورت پیش‌فرض در بر دارد. WTLS همچنین بر لایه بالایی روندنمای اتصال بر لایه مخابراتی (قابل مقایسه با UDP و TCP در اینترنت) کار می‌کند.
و سرانجام، پروتکل WTLS فرمت گواهی‌نامه خود را از نظر اندازه - در پهنای باند محدود - تعریف و بهینه می‌سازد، اما گواهی‌نامه رایج X.509 را نیز پشتیبانی می‌کند.
3-4- مسایل پیاده‌سازی29
امروزه مرورگرهای رایج پروتکل SSL/TLS، به‌عنوان پیش‌فرض پیاده می‌شود. البته نت‌اسکیپ نگارش 4. 7 - تا زمانی که نگارش 6 و بالاتر آن و ویندوز اکسپلورر 5 و 6 هر دوی SSL و TLS را پشتیبانی کردند - تنها SSL را پشتیبانی می‌کرد.
هنگامی‌که زیربنای معماری سیستم بانکداری الکترونیکی ارایه شد، بسیاری از بانک‌ها ترجیح می‌دادند که از پروتکل SSL/TLS - که از طریق مرورگرها یا برنامه‌های کاربردی مستقل اجرا می‌شود - استفاده کنند.
به‌عنوان یک جایگزین برای برنامه کاربردی بانکداری الکترونیکی بر مبنای مرورگر، یک برنامه کاربردی مستقل - که هم امنیت لازم را فراهم می‌کند و هم عملیات بانکی را انجام می‌دهد - می‌تواند به‌کار آید.
گاه یک برنامه کاربردی مستقل تنها به‌عنوان یک پراکسی30 روی کامپیوتر کاربر نصب می‌گردد تا میان مرورگر و کامپیوتر بانک قرار گیرد و امنیتی نیرومند را برای ارتباط میان کاربر و بانک برقرار کند. در بسیاری موارد، برنامه‌ای که شامل امنیت قوی باشد و امکان انجام عملیات بانکی را نیز داشته باشد، به‌صورت اپلت31 بر کامپیوتر کاربر فرستاده می‌شود و به‌عنوان یک پراکسی میان مرورگر و بانک عمل می‌کند.
3-5- تکیه‌گاه‌های اعتماد
یک کاربر زمانی می‌تواند به اجرای درست و رابط کاربر برنامه کاربردی بانکداری الکترونیکی اعتماد کند که یک نسخه اصلی از برنامه کاربردی مستقل مرورگر را داشته باشد. اگر یک اپلت جاوا به‌کار رود، باید به‌طور دیجیتالی توسط بانک تایید شود، به‌گونه‌ای که کاربر پیش از اجرای برنامه بتواند آن‌را بررسی و تایید کند. کاربران باید تشخیص دهند که آیا به‌راستی با بانک در ارتباط هستند یا نه؟
در صدر همه این‌ها، باید یک زیرساخت کلید عمومی (PKI32) پرمعنی وجود داشته باشد. یک PKI، ارتباط درست کلیدهای عمومی با موجودیت‌ها را تضمین می‌کند. نام موجودیت به‌همراه کلید عمومی مربوطه در یک مجوز X.509 قرار می‌گیرد و مجوز اصلی توسط CA33 تایید می‌گردد که برای توزیع درست بسیار مهم است. و اگر اعتبار کاربر برپایه این مکانیزم باشد، این‌ها توسط بانک برای بررسی مجوز موجودیت‌ها به‌کار می‌رود. کاربر نیز برای تایید بانک - در هنگام اعتبارسنجی SSL/TLS و بررسی امضای دیجیتالی اپلت‌ها - به آنها نیاز دارد.
اعتبارسنجی بدون وجود مجوز اصلی معتبر، نمی‌تواند اجرا شود. امروزه مجوز اصلی به‌همراه نصب مرورگرها در سیستم کاربر نصب می‌گردد. اگر سیستم بانکداری الکترونیکی برمبنای برنامه کاربردی منتقل شود در فایل تنظیمات34 جای می‌گیرد. در همه این موارد، حفاظت از این مجوزها به‌عهده سیستم عامل است.
3-6- محدودیت‌های صادراتی
از قدیم، محدودیت‌های صادراتی اعمال شده توسط امریکا، از صادرات مرورگرهایی که رمزنگاری توانمند داشته باشند، جلوگیری می‌کند. در امریکا، طول مرورگرهای صادراتی کلید رمزنگاری متقارن تا 40 بیت و غیرمتقارن تا 512 بیت محدود بود. پس از رفع محدودیت‌ها، موسسات مالی اجازه یافتند که از رمزنگاری قوی - که در مرورگرها موجود بود - استفاده کنند.
از دیدگاه تکنیکی، این کار از طریق یک سرور ویژه صدور مجوز با کاربردهای ویژه انجام می‌پذیرفت. برای این دستگاه‌ها واژگانی گوناگون - مانند: SGC مایکروسافت35 و نت‌اسکیپ بین‌المللی36 و سرور جهانی وری‌ساین37 - به‌کار می‌رفت. از سال 2000 نیز نرم‌افزارهای رمزنگاری بدون هیچ محدودیتی به دیگر کشورها صادر شد. و هرچند که پیاده‌سازی SSL/TLS بر مرورگر همچنان به‌کار می‌رود، اما یک سوم بانک‌های بررسی شده در این پژوهش، آن‌را به‌کار نمی‌برند.
4- اعتبارسنجی کاربر
تامین امنیت کانال ارتباطی - از کاربر تا بانکی که اعتبار داده - تنها بخشی از سیستم امنیت بانکداری الکترونیکی است و بخش‌های دیگری هم در این کار وجود دارد.
4-1- موجودیت در برابر اعتبارسنجی تراکنش
باید یک تفکیک مهم میان تصدیق موجودیت و تصدیق تراکنش‌ها قایل شد. تصدیق موجودیت یعنی اینکه مشتری تصدیق می‌کند که آغاز به برقراری ارتباط با بانک کرده است؛ اما تصدیق تراکنش یعنی آن‌که همه تراکنش‌ها - در طول این تماس - توسط مشتری تایید می‌شود.
بسته به مکانیزم اعتبارسنجی، تصدیق تراکنش می‌تواند انکار ناپذیری را فراهم آورد، اما در تصدیق موجودیت این امکان فراهم نمی‌شود. امروزه این تفکیک در سیستم‌های بانکداری الکترونیکی به‌وضوح اعمال می‌شود. برخی از سیستم‌ها تنها تصدیق موجودیت دارد و در برخی دیگر تصدیق تراکنش هم هست.
4-2- مکانیزم تصدیق
4-2-1- رمز با طول ثابت
دوسوم از بانک‌های بررسی شده در این پژوهش هنوز برای تایید کاربر در سیستم‌های بانکداری الکترونیکی، ، متکی به رمز با طول ثابت هستند. این رمز ممکن است یک شماره شناسایی شخصی (38PIN) یا یک رمز بر مبنای حروف و ارقام بی‌ربط به مشخصات کاربر باشد تا به‌سادگی حدس زده نشود و امنیتی را در برابر رسوخ‌گران فراهم آورد و ممکن است که بانک هر از گاهی مشتری بخواهد که رمزش را تغییر دهد.
رمز با طول ثابت بیشتر برای تشخیص هویت مشتری به‌کار می‌رود و کمتر برای احراز اعتبار تراکنش‌ها به‌کار برده می‌شود. از ترکیب این روش و مکانیزمی که در بخش‌های زیر توضیح داده می‌شود، برای اعتبارسنجی تراکنش نیز استفاده می‌شود. رمزها نباید به‌روشنی در شبکه فرستاده شود، زیرا کسانی هستند که این رمزها را درمی‌یابند. اگرچه این روش از گذشته، ریسک بالایی داشته، اما به‌دلیل سادگی، کاربرد بسیاری دارد.
4-2-2- رمز پویا39
گاهی از اوقات، بانک‌ها لیستی از رمزهای یک‌بارمصرف را برای کاربران خود می‌فرستند. این رمزها تنها یک‌بار به‌کار می‌روند و امنیت بالایی دارند. اما اشکال عمده در به‌یادسپاری آنها است و باید بر جایی - مانند کاغذ یا کامپیوتر - نوشته شود، که بسیار خطرناک است. واژه‌ای که بانک‌ها به‌کار می‌برند فهرست اعداد مخدوش40، بیشتر برای احراز اعتبار موجودی و شماره تراکنش برای تایید تراکنش‌های مستقل است.
برخی از سیستم‌ها آمیزه‌ای از رمزهای ثابت و پویا را به‌کار می‌برند: ثابت برای احراز اعتبار موجودی و پویا برای تایید تراکنش‌ها. به‌جای صدور لیست رمزهای مستقل، ممکن است که زنجیره‌ای از رمزهای وابسته و یک‌بار مصرف تولید و به‌کار برده شود و این کار نیاز به یک نرم‌افزار اضافه بر دستگاه کاربر دارد.
4-2-3- پرسش / پاسخ41
ایده پرسش/پاسخ این است که کاربر با ارایه برخی اطلاعات محرمانه شخصی، خود را - از طریق احراز اعتبار موجودی - به بانک معرفی می‌کند. البته نه با فرستادن مستقیم این اطلاعات، بلکه با پرسش و پاسخ تصادفی، هر بار بخشی از اطلاعات سری را به بانک می‌دهد و بانک با استفاده از جواب‌های دریافتی مشتری را شناسایی می‌کند.
طرح‌های متقارن و غیرمتقارن سیستم پرسش/پاسخ وجود دارد. برای نمونه، پاسخ یک طرح متقارن یک کد تایید پیام در زمانی ویژه یا پرسشی تصادفی از بانک را در بر دارد. امضای دیجیتالی در پرسش/پاسخ‌های تصادفی نیز، نمونه غیرمتقارن است. این طرح‌ها بیشتر با رمزهای سخت‌افزاری پیاده‌سازی می‌شود.
4-2-4- SSL/TLS/WTLS
در واقع، به‌کارگیری امضای دیجیتالی برای طرح پرسش/پاسخ در پروتکل SSL/TLS/WTLS اختیاری است. هنگامی‌که یک کانال ایمن میان کاربر و بانک به‌وجود می‌آید، کاربر نیز می‌تواند با امضای دیجیتالی، به‌روشنی احراز اعتبار گردد. اغلب کلید امضای خصوصی در کامپیوتر کاربر ذخیره شده، تنها با یک رمز حفاظت می‌شود.
هم‌اکنون این روش به‌دلیل محدودیت‌های جاری در سیستم بانکداری بی‌سیم (WAP) به‌کار نمی‌رود.
4-2-5- امضای دیجیتالی
در کنار احراز هویت موجودیت، امضای دیجیتالی نیز می‌تواند برای تایید تراکنش به‌کار رود. این امن‌ترین راه جایگزین است؛ اما از مرورگرهای امروزی، تنها نت‌اسکیپ مکانیزم جاوااسکریپت را برای استفاده از امضای دیجیتالی - در جایی مانند محتوای یک فرم - فراهم آورده است.
یک‌هفتم از بانک‌های پژوهش ما - در سیستم‌های بانکداری الکترونیکی - پیاده‌سازی ویژه خود یا یک برنامه کاربردی مستقل و یا یک اپلت را برای امضای دیجیتالی به‌کار می‌برند.
همان‌گونه که پیشتر گفته شد، اغلب، کلید امضای خصوصی روی کامپیوتر کاربر ذخیره شده، تنها با یک رمز حفاظت می‌شود. افزون بر این کلیدهای رمزنگاری در نرم‌افزار بسیار آسیب‌پذیر است. و اطمینان روش رمز پویا بیش از رمز با طول ثابت است.
4-2-6- مجوزهای سخت‌افزاری42
برخی از مکانیزم‌های یاد شده می‌تواند با روش مجوز سخت‌افزاری پیاده‌سازی شود. کلیدهای امضای دیجیتالی خصوصی برای احراز هویت تراکنش روی کارت‌های هوشمند43 ثبت و نگهداری گردد.
به‌دلیل هزینه‌ای که کاربرد کارت هوشمند برای کاربران دارد، این روش کمتر به‌کار می‌رود؛ اما کاربرد کارت هوشمند برای تایید هویت - در پول الکترونیکی و کارت شناسایی - کاربرد دارد.
البته باید توجه داشت که هیچ‌گاه به امنیت کامل نخواهیم رسید، بلکه با هزینه بیشتر، امنیتی بیشتر به‌دست می‌آید. امنیت در کارت‌های هوشمند نیز - به‌دلیل وجود حملات پیشرفته کنونی - چندان قابل اعتماد نیست.
دستگاه‌های موبایل - مانند PDAها یا کارت پول بی‌سیم - می‌تواند امنیت سیستم بانکداری مبتنی بر WAP یا اینترنت را افزایش دهد. این دستگاه‌ها مشخص هستند و برای هر دو منظور احراز هویت فردی یا تراکنش می‌توانند پروتکل رمزنگاری را اجرا کنند.
توافق روی یک مجوز ورود ممکن است به یک سناریوی فاجعه‌آمیز بیانجامد و آن زمانی است که بانک بخواهد یک مجوز تازه برای کاربران صادر کند. برای پیشگیری از این کار، همه مجوزها باید کلیدهای رمزنگاری گوناگون داشته باشند.
هنگامی‌که از کلیدهای نامتقارن استفاده شود، مشکلی به‌وجود نمی‌آید؛ اما زمانی‌که کلیدهای متقارن به‌کار می‌رود، به یک بانک اطلاعاتی امن برای نگهداری کلیدهای کاربران بر کامپیوتر بانک نیاز است. کلیدهای متقارن اغلب با یک شماره سریال منحصر به‌فرد مربوط به مجوز - به‌همراه یک کلید اصلی که برای همه مجوزها یکسان است - رمزنگاری می‌شود. در این صورت هر کاربری در کلیدی جداگانه، با بانک مشترک می‌شود، بدون آن‌که مشکل امنیتی بانک اطلاعاتی پیش آید.
5- مطالب بیشتر راجع به امنیت
امنیت ارتباطی یعنی تهیه یک کانال امن میان کاربر و بانک اعتباری و احراز هویت وی و تراکنش‌ها. این‌ها دو موضوع اصلی امنیت است که در سیستم‌های بانکداری الکترونیکی به‌کار می‌رود، اما برخی مطالب امنیتی دیگر هم وجود دارد که متاسفانه در عمل بسیار هم بحرانی می‌شود.
5-1- ثبت‌نام44
پیش از آن‌که یک کاربر بتواند از یک سیستم بانکداری الکترونیکی وارد شود، باید به‌نوعی ثبت‌نام کند. کاربر ناگزیر است که به روشی، نخستین ارتباط خود را با بانک برقرار گرداند تا پس از آن، بانک همواره بتواند وی را احراز هویت کند.
اغلب برای نخسین ارتباط با بانک، یک رمز اولیه به‌کار برده می‌شود که کاربر از طریق پست کاغذی یا با رفتن به یک شعبه بانکی این رمز را دریافت می‌کند.
گاه نیز احراز هویت کاربر از طریق تلفن هم امکان‌پذیر است. در این‌صورت، کاربر از طریق اپراتور به پرسش‌هایی که بر صفحه نمایش می‌آید، پاسخ خواهد داد.
5-2- وکالت و نمایندگی45
در برخی شرایط، توانایی پذیرش نمایندگی در سیستم بانکداری الکترونیکی یک آرزو است. برای مثال، مدیر یک شرکت علاقه‌مند است که به کارمندی این اختیار را بدهد که بتواند به سیستم بانکی دسترسی پیدا کند، یا یک پدر بخواهد به فرزندانش وکالت یا نمایندگی بدهد.
اگر احراز هویت برپایه رمز با طول ثابت باشد، این مساله ساده است و کافی است که وی رمز را بداند؛ اما اگر احراز هویت امنیتی بیشتر داشته باشد، این کار مشکل‌تر خواهد بود و اگر از طریق کارت هوشمند انجام شود، تهیه کپی از کارت به‌سادگی انجام‌پذیر نیست.
تنها اندکی از سیستم‌های بانکداری الکترونیکی هستند که مکانیزم واقعی نمایندگی را اجرا می‌کنند. برای نمونه، دارنده شماره حساب بانک می‌تواند یک رمز حفاظت‌شده تازه ایجاد کند که اجازه انجام این کار را در اندازه‌ای محدود انجام دهد.
5-3- بسترهای امن46
زمانی که از ایجاد کانال امن ارتباطی میان کاربر و بانک اعتباردهنده و احراز هویت او سخن می‌گوییم، فرض بر این است که سیستم‌عامل کاربر و نرم‌افزار مربوطه، امنیت لازم را برقرار می‌کند. اما متاسفانه اغلب چنین نیست و بسترهای مورد استفاده کاربر بسیار آسیب‌پذیر هستند. ویروس‌ها و انواع برنامه‌های آلوده‌کننده می‌توانند به مستندات هویتی - که در کامپیوتر مشتری نصب شده - رخنه کنند. آنها می‌توانند کلیدهای اختصاصی مشتریان را بدزدند، یا مشتریان را از طریق رابط‌کاربر دست بیاندازند. یا حتی او را به راهی دیگر - جز اتصال به بانک - ببرند.
برای نمونه، اگر سیستم بانکداری الکترونیکی یک پراکسی بر دستگاه کاربر - که نقطه پایانی کانال امن به بانک را فراهم کند - را در بر داشته باشد و آن‌را میان مرورگر کاربر و وب‌سرور بانک جای دهد، یک برنامه مخرب می‌تواند در ارتباط میان مرورگر و پراکسی وقفه اندازد.
حتی کارت هوشمند هم از این مشکل به‌دور نیست. اگر کارت هوشمند با صفحه کلید کامپیوتر از حالت قفل خارج شود، یا کاربر از طریق یک رابط جعل‌شده اقدام به گرفتن PIN کند، کد PIN سرقت‌پذیر خواهد بود.
بنابراین بهتر است که از یک دستگاه کارت‌خوان ویژه کارت هوشمند - که دارای نمایشگری کوچک است - استفاده شود و دیگر نیازی به استفاده از کامپیوتر کاربر نباشد.
ویژگی‌های عمومی این‌گونه کارت‌خوان‌های امن، رو به گسترش و تولید است. بیشتر کارت‌خوان‌های کنونی تنها یک شکاف برای واردکردن کارت هوشمند دارند. یک اتحادیه صنعتی به‌تازگی بر مکانیزمی کار می‌کند که اعتماد بیشتری را جلب کرده، امنیتی بیشتر را هم در بستر محاسباتی کاربر نهایی برقرار می‌سازد.
همچنین سرور بانک باید یک نقطه پایانی امن در سیستم بانکداری الکترونیکی ایجاد کند. کاری مناسب باید انجام شود تا دزدان نتوانند به سایت‌ها دستبرد بزنند. سخن پیرامون این کارها بیرون از حیطه این نوشتار است، اما اطلاعات بیشتر در منابع موجود است.
5-4- عامل انسانی
این حقیقت که بستر کاربر امن نیست، اغلب به‌دلیل ناآگاهی وی از مسایل امنیتی است. درست است که بستر مورد استفاده کاربر امنیت لازم را برقرار نمی‌کند، اما بیشتر مشکلات امنیتی توسط کاربر دقیق و آگاه به مسایل امنیتی، قابل پیشگیری است. کاربران باید رمزهای خصوصی، لیست رمزهای یک‌بار مصرف، مجوزهای سخت‌افزاری و دیگر موارد را حفاظت کرده و به‌درستی از آنها استفاده کنند. کاربران باید نرم‌افزارهای ضدویروس را بر دستگاه خود نصب و به‌روزرسانی کنند. کاربران نباید برنامه‌های فرستاده شده از سوی فرستندگان ناشناس را باز کنند و رمزهای خود را در معرض دید دیگران قرار ندهند.
بانک‌ها باید اطلاعات لازم در این زمینه را به مشتریان خود بدهند و مسوولیت این چیزها را به مشتری گوشزد کنند تا آنها بیشتر دقت کنند. اپراتوری بانک‌ها نیز باید در زمینه امنیت کامپیوتر آموزش ببینند.
5-5- ورود به کامپیوتر و کنترل عملیات47
در بخش‌های پیشین، روشن شد که چیزی به‌نام امنیت کامل وجود ندارد. اگر نیرومندترین سیستم امنیتی را هم برقرار کنیم، باز نقاط ضعفی خواهیم داشت. از آنجا که شکاف‌های امنیتی به‌طور کامل قابل پیشگیری نیست، بانک‌ها با کنترل بر ورود کاربران به سیستم و کنترل عملیات آنها، کمک می‌کنند که برخی از خطرات امنیتی کشف گردد یا در آینده دریابند که چه اتفاقی افتاده است؟
این مکانیزم کشف می‌تواند از آغاز ورود به بانک تا انجام عملیات و کارهای بانکی ادامه یابد. برای نمونه، اگر کاربری اطلاعاتی نادرست رابه کامپیوتر بدهد، سیستم باید به بانک هشدار دهد.
6- جمع‌بندی
همان‌گونه که فناوری پیشرفت می‌کند، بیشتر کارهای روزانه زندگی نیز به‌سوی برخط شدن پیش می‌رود. بانکداری الکترونیکی یکی از مهم‌ترین نمونه‌های این روند است. چیزهایی که در این نوشتار بحث شد، می‌تواند در تجارت الکترونیکی، دولت الکترونیکی و دیگر خدمات الکترونیکی هم کاربرد داشته باشد.
نخستین موضوع مهم امنیت، ایجاد یک کانال امن است. داده‌ها یکپارچه و با اطمینان میان کاربر و بانک تبادل می‌شود. دومین موضوع مهم امنیت هم احراز هویت کاربر در آغاز ارتباط وی با بانک است.
درباره نخستین موضوع باید گفت که بیشتر سیستم‌های بانکداری الکترونیکی امروزی متکی به پروتکل SSL/TLS/WTLS هستند. اگرچه برخی راه‌حل‌های دیگر هم وجود دارد، اما استفاده از این پروتکل - به‌خاطر آن‌که بیشتر مرورگرها آن‌را پشتیبانی می‌کنند - مشهورترین روش است.
درباره دومین موضوع نیز باید گفت که رمزهای ثابت همچنان به‌گستردگی به‌کار خواهد رفت، زیرا کاربردی ساده دارد؛ اما از دیدگاه امنیتی، رمزنگاری کلید عمومی بهترین راه‌حل است. هرچند که در عمل، کلید خصوصی کاربر اغلب بر نرم‌افزار ثبت می‌شود و تنها با یک رمز محافظت می‌گردد.
کارت‌های هوشمند و کارت‌خوان‌ها نیز، راه‌حلی گران را ارایه می‌کنند و شاید بهترین راه - که هماهنگی میان هزینه و امنیت دارد - مجوز سخت‌افزاری است.
حتی بهترین راه‌حل هم بستگی به این دارد که سیستم چه‌اندازه قابل اطمینان باشد. کاربر مسوولیت امنیت دستگاه خویش را - به‌هر روش ممکن - دارد و در این راه، آموزش کاربران تاثیر به‌سزایی بر کار می‌گذارد. البته بانک هم در جایگاه خودش مسوول برقراری امنیت سرورهایش است.
امنیت فراتر از همه هزینه‌ها و خطرات است. در یک سیستم بانکداری الکترونیکی - تا زمانی که یک حداقل محافظتی انجام شود - هزینه‌های برقراری امنیت در دستگاه کاربر تا جای ممکن، کاهش می‌یابد.
یک روش و یک نفر به‌تنهایی نمی‌تواند امنیت را برقرار کند و همه باید روش‌های گوناگون را بیازمایند؛ هرچند که برخی از آنها خطا باشد.
پی‌نوشت :
1 Automated Teller Machines
2 User Graphic Interface
3 Wireless Application Protocol
4 Web Browser
5 World Wide Web
6 Internet / Web Banking
7 Web Server
8 Client/Server
9 Java
10 Gateway
11 WAP Proxy
12 Confidentiality
13 Data Authentication
14 Entity Authentication
15 Non-Repudiation
16 Interface Server
17 Authentication Server
18 Transaction Server
19 Main Frame
20 Microsoft Passport
21 Secure Sockets Layer
22 Netscape
23 Transport Layer Security
24 Wireless Transport Layer Security
25 Secure Channel
26 Handshake and Data Transfer
27 Message Authenticated Code
28 Dobbertin
29 Implementation
30 Proxy
31 Applet
32 Public Key Infrastructure
33 Certification Authority
34 Configuration File
35 Microsoft's "Server Gated Cryptography"
36 Netscape's International "Step-Up"
37 Verisign's "Global Server ID"
38 Personal Identification Number
39 Dynamic Password
40 Scratch List Number
41 Challenge/Response
42 Hardware Tokens
43 Smart Cards
44 Registration
45 Delegation
46 Secure Platforms
47 Logging and Monitoring
- ۸۴/۰۲/۱۲
